Home

Products and Services

Support

Contact Us

Home -> Support -> FAQs -> Asterisk SLA

Asterisk SLA (Shared Line Appearances)

Contents
Terminology General principles of operation of Shared Line Appearances What does Asterisk support in terms of BLF and SLA? What is the problem with using IP Phone Line Keys? Prerequisites for Asterisk SLA The SLA.CONF configuration file Configuring the Aastra 53i Phone for SLA Configuring the Grandstream GXP2000 Phone for SLA EXTENSIONS.CONF: Setting the Hints used by SLA EXTENSIONS.CONF: Dial plan for Inbound calls using SLA Asterisk function SLATrunk() EXTENSIONS.CONF: Dial plan for Outbound calls using SLA Cases that must be handled in your dial plan On-hook dialling and use of the phone's own line keys How do we handle the different cases in the dial plan? Improving the dial plan to handle more cases Asterisk function SLAStation() What is good and what is bad about the Asterisk implementation of SLA?

Terminology and SLA Concepts

Terminology We have attempted to use the correct terminology (as recognised throughout the telephony industry) within the explanations on this web page. However, as it is so important to be clear about the meaning of the terminology used here, it seemed like a good idea to set it out explicitly at the start: Asterisk Server or Asterisk PBX refers to the Asterisk server that is being used as a PBX or Business Phone System. In this role, it would have some trunk lines connecting it to the public telephone network (PSTN) and some extensions that would typically be used as desk phones. The trunks could be analogue lines, ISDN (PRI or BRI), SIP trunks, etc. Asterisk SLA feature refers to the enhancements added in version 1.4 to support shared line appearances, including the new configuration file sla.conf BLF (Busy Lamp Field) originally referred to a panel of lamps showing the status of every extension. This would be located alongside the receptionist's phone so they could see at a glance which extensions were in use. The BLF terminology has come through into modern phones to refer to the functionality of a having a lamp indicating the current status of another phone on the system. Extensions or extension phones are the local phones that connect directly to the PBX. In Asterisk, these could be IP phones, softphones, analogue phones (POTS) etc. Asterisk SLA documentation tends to refer to these as "stations". (Note: Don't be confused by the configuration file extensions.conf which contains the "dial plans" for the Asterisk PBX and does not contain a list of extensions) Key Telephone System (also known as KSU) is a legacy business phone system still used extensively by many small businesses. It shows the status of

is a legacy business phone system still used extensively by many small businesses. It shows the status of the trunk lines on every desk phone using a number of line keys. The trunk lines on KSU's would almost always be analogue. Key Telephone Systems - Wikipedia Shared line keys are the combined key/lamp buttons on a phone-set that show the status of a trunk line and can be used to access that line (e.g. to make a call on that line or answer a ringing call on that line). Originally found on the key telephone units (KTU's) of key telephone systems, but inherited through to modern IP phones. SLA (Shared Line Appearances) are explained in a paragraph below Trunks or "trunk lines" are the lines that link the Asterisk PBX to the public telephone network (the PSTN) You may also find this link useful: Business Telephone Systems - terminology (BBC website guide) General principles of operation of Shared Line Appearances The shared line key should have a lamp either under the key or next to it. At any given moment, the lamp shows the status of the corresponding line - this is shown on every phone that has access to the line and is equipped with the shared line key feature. When an incoming call arrives, it may ring one or more of the extension phones, but it will also appear as a flashing light on the lamp next to the relevant shared line key. If a user wants to answer the call when it is ringing they simply press the button for that line. After the call has been answered, the lamp for that line will be on continuously. Other users can join the call by pressing the button for that line - in effect they become conferenced into the call. Calls can be parked (put on hold) and then any user can retrieve the call by pressing the button for that line. When the call ends, the lamp for that line goes out. Calls are transferred by first putting the call on hold, then telling the other user to pick up the call on the relevant line. For example, if user A wants to transfer the call on line 2 to user B, they would press the "Hold" button on their phone, then call user B and tell user B to pick up the call on line 2. User B would end the call with user A and immediately press the shared line key for line 2. When a user wants to make an outbound call, they press the button for any of the trunk lines that are not already in use. It is easy to see which lines are free because the lamp will not be on. As soon as they press the button, the lamp for that line comes on (on every phone) and the user who selected the line hears dial tone. They dial the number and make the call.

What does Asterisk support in terms of BLF and SLA?

Busy Lamp Field vs Shared Line Appearance It is easy to think that one status lamp is much the same as another on a telephone system. However, the distinctions between Busy Lamp Field and Shared Line Appearance lamps for Asterisk is of great importance. A Busy Lamp Field is normally used to show the status of extensions whereas SLA is essentially showing the status of trunk lines. Asterisk support for BLF Asterisk uses "hints" to support basic BLF functionality. These are lines within the dial plan in extensions.conf that map a nominal "name tag" with a specific device whose state is known to Asterisk. If the device you want to monitor is an extension phone, then the name tag is likely to be the extension number. It is recommended that you use the subscribecontext parameter in sip.conf to avoid any possible confusion about the location of hints in extensions.conf. extensions.conf example: exten => 2001,hint,SIP/2001 exten => 3002,hint,Zap/6 BLF involves a cooperation between the IP phone and the Asterisk server. Asterisk supports BLF through the use of hints in the dial plan, but the phone must subscribe (using SIP SUBSCRIBE requests) to participate. The subscription it sends will be associated with a particular key/lamp on the phone-set. On the Aastra and Grandstream GXP2000 phones this is done using the programmable keys (Grandstream calls them Multi-Purpose keys) by setting them to be of type BLF and then setting the value field to match the name tag used in the hint e.g. the extension number of the phone you want to monitor. Asterisk support for SLA Support for SLA was introduced in Asterisk version 1.4 after a lot of requests and general disgruntlement in Digium and other forums. If you are wondering why there is such demand for an old technology like SLA to be available on very new technology like Asterisk and IP phones, click here (opens a pop-up window with a brief explanation) The documentation for Asterisk SLA provided on the wiki and by Digium is somewhat limited and it is not altogether obvious how to use it. I suspect it is not widely used and that many of the resellers who were clamouring for it were not very impressed when they saw the result - it has to be said that the Asterisk implementation of SLA does not work seemlessly with any of the IP phones used in our tests. With one IP phone we tried it did not work at all. Circumstantial evidence suggests that some of the other VoIP solution providers - Broadsoft, PBXnSIP, Sylantro etc - have found much better ways to integrate SLA with commonly available IP phones than Digium has managed. I would be very pleased to

better ways to integrate SLA with commonly available IP phones than Digium has managed. I would be very pleased to hear your views on this or any other aspect of SLA and the advice available on this web page - send me an email at info(AT)smartvox.co.uk. The Asterisk SLA feature relies on hints in much the same way as described above for BLF. The control of the key-lamps on the IP phone requires a SIP subscription to be established with the Asterisk server. All the IP phones we tested could only do this using a key programmed for the BLF function and not with a key programmed as a "shared line". This is hugely disappointing and leaves you thinking there must be a better way of doing SLA, but Digium haven't yet discovered what it is. So, to make Asterisk SLA work, you must configure BLF function keys on the IP phone, hints in the extensions.conf file, entries in the SLA.CONF file and dial plans to handle inbound trunk calls and outbound dialling in extensions.conf. To get the best user experience, a little care is also required with other configuration options on the IP phones. Unfortunately, some makes and models of IP phone are much better suited to Asterisk SLA than others. For example, the Linksys SPA941 does not play nicely at all with Asterisk SLA because it doesn't have suitable programmable keys. Shared Line Appearances and IP Phone Line keys First the bad news. Phones like the Aastra 53i, the Grandstream GXP2000 and Linksys SPA941 have permanently assigned line keys. If you think the Phone's own Line Keys can be directly mapped to the trunk lines on a small Asterisk PBX, then prepare to be disappointed. For a more detailed discussion about the different types of line keys and buttons on a typical IP phone, please refer to the section below Programmable Keys vs Line Keys. Programmable keys to the rescue Now the slightly better news. Most IP phones have programmable keys that can be used with the Asterisk Shared Line Appearance feature. The Aastra range of IP phones is one example. Smartvox have tested the feature using the Aastra 53i, but the slightly higher spec 55i and 57i models would actually be more appropriate because they have a better display and more keys. We have also tested SLA with a Grandstream GXP2000 (software version 1.1.6.16), a Snom 360 and a Linksys SPA941. On the Grandstream you use the "Multi Purpose Keys" which are shown under the Basic Settings tab. The Snom 360 has various fixed assignment keys, but also has a bank of 12 programmable keys. To get the Snom to work with Asterisk SLA, it once again proved necessary to set the key type as "BLF", even though the options include both "line keys" and "shared line keys". As mentioned above, the Linksys SPA941 does not have programmable keys so it is virtually impossible to configure it to work with the Asterisk SLA feature.

What is the problem with using IP Phone Line Keys?

Programmable Keys vs Line Keys Programmable keys are not the same as the "line keys" on a multi-line phone. The line keys generally represent channels from the phone to the PBX (or possibly direct to the VoIP service provider). Each line key can be associated with a different VoIP account. In use, each line key will be associated with a different call (when more than one call is connected to the phone). However, they do not represent trunk lines - if you start thinking that they do while trying to configure Asterisk SLA it is likely to lead to your brain exploding or your needing to lie down in a dark room for some time. To appreciate the difference, just think what happens when you make an internal call - it uses the first line on the phone to connect to the PBX, but it does not use the first trunk on the PBX. If you put a call on hold and make an enquiry call to a colleague, it uses the second line on your IP phone, yet that enquiry call has absolutely no cast-iron connection with trunk line 2 on the PBX (even if the call that is on hold is using trunk line 1).

Click to view larger image

The line keys on those IP phones tested by the author simply could not be programmed to have all the characteristics required to correctly participate in the Asterisk SLA system. The conclusion reached by the author is that phone line keys alone cannot be used for Asterisk Shared Line Appearances. They cannot always give you a one-to-one mapping between each line key and each shared trunk on the PBX. In particular it is very unlikely that you can make Asterisk control the lamps on such line keys correctly. Instead use a group of "programmable keys". This provides a useable solution and keeps the configuration reasonably simple. However, it is usually possible to make the line keys act as if they were shared line keys for a subset of functions. In particular, to make an outbound call on a specific trunk the line keys can mimic the behaviour of the equivalent shared line keys provided the phone has an auto-dial function. More details are given later - see On-hook dialling and use of the phone's own line keys.

details are given later - see On-hook dialling and use of the phone's own line keys. On this web page we concentrate mainly on showing you how to configure basic SLA operation centred around the use of programmable keys configured for Asterisk SLA. This generally means setting the programmable keys for the BLF function. Please feel free to contact Smartvox Limited if you want to discuss this in more detail or would like a quotation for an installed solution. Call John on 01727-221221 or email us at info(AT)smartvox.co.uk.

Prerequisites for Asterisk SLA

Asterisk version 1.4.17 or later It took a while for Digium to fix some of the bugs in SLA and versions earlier than 1.4.17 are likely to contain bugs, some of which have a serious impact on the reliability of SLA. Single channel trunk lines The way that SLA works means that it only makes sense if the trunk lines represented by each key/lamp are single channel "circuits". That is, each trunk line can only carry one call at a time. If your trunks are analogue lines then this will already be the case anyway (after all, the whole concept was inherited from key telephone systems that worked with analogue circuits). If you want to use SLA with a SIP trunk, or perhaps a BRI trunk, capable of carrying multiple simultaneous calls then you will have to do some tricks in the dial plan to identify if a call is the first, the second etc on that trunk. The trunk number can usually be identified by inspecting the value of ${CHANNEL} - this is an internal Asterisk channel variable. The examples shown here assume that each trunk, even when the trunk is a SIP connection, is a single channel device or connection. Programmable keys on the IP phones The programmable key must be able to operate in a role where it subscribes to call event notifications for a specific device ID. The lamp next to it must show the state of the device that has been subscribed to. When pressed, the key must issue an INVITE (i.e. try to make a call) to the device ID that has been programmed for that key. It can use the authorisation credentials of the main account on the phone when subscribing and calling. The BLF key type is suitable on Aastra 5x, Grandstream GXP2000 and Snom 360 phones. Just because a phone-set does not have the correct type of programmable keys, this does not mean that it cannot participate at all in the SLA system. A phone that does not have suitable buttons can still be included in the "ring group" as defined in SLA.CONF and it will ring when an incoming call arrives on the trunk line. The user can answer the call and Asterisk will correctly show the line status as "in use" on all the other stations which do have suitable status lamps. The other phones can join the first one in a conference by pressing their trunk line buttons. Through cunning workarounds in the dial plan it should even be possible for the incompatible phone to make an outbound call using one of the trunk lines and for the status lamps on the other phones to be updated correctly. Manual configuration of Asterisk conf files This is not mandatory for SLA, but it is assumed in the explanations given here. At Smartvox we have always preferred manual configuration of conf files over any of the GUI interfaces such as FreePBX or AsteriskNow. It gives far more flexibility and forces you to understand how the systems work in detail. It also means that the only bugs you have to contend with are those in the core program plus those in your own configuration! Autocontext In keeping with the strategy of manual configuration, the "autocontext" parameter is not used in the examples described on this web page. Autocontext is an optional parameter in SLA.CONF that automatically and dynamically creates entries in the dial plan of Asterisk. We recommend that autocontext is not used - at best, it saves you typing a few lines in the dial plan, but the penalties you then pay in terms of inflexibility in the dial plan leading to a poor user experience (not to mention an annoying quirk whereby the "dialplan reload" command will erase all the auto-created entries) completely outweigh the minor benefits of less typing. For the sake of those readers who are too timid to discard autocontext, we will point out the parts of the dial plan where it could be used, but generally all the descriptions given in this article assume that autocontext is disabled. When a sample of dial plan is shown that is incompatible with autocontext we will bring this to your attention.

About the examples and conf file samples used in this article
The following sections will guide you through the setup of a small Asterisk system using shared line appearances. Each step is explained to show how it works. The dial plan examples will start with a fairly simple configuration and we will then gradually improve the dial plan to make it handle a broader range of user actions. All examples are based on a setup with two IP phones being used as extensions (or stations) and two shared trunk lines. The device types used for the trunk lines are not completely fixed and may vary a little from example to example this is to show you how the configuration would be done for different technologies. For example, we will illustrate how to use zap FXO trunks, Pika FXO and a single channel SIP account such as you might have with a VoIP service provider.

The examples are taken from a test rig using a Grandstream GXP2000 configured as extension 4001 and an Aastra 53i configured as extension 4003. Details for other makes and models of phone will be added as and when those phones become available for inclusion in our test rig. If you are in a position to provide an IP phone on loan that you would like to see included then please contact John using the phone or email contact details provided on this web site. Dial patterns used in the examples The dial plans on the test rig are based on the assumption that internal extensions all have 4 digit numbers - analogue extensions are 3001, 3002, etc and IP phones are 4001, 4002, 4003 etc. PSTN numbers are assumed to start with zero and to be more than 5 digits long.

The SLA.CONF configuration file

Core entities: Trunks and Stations SLA.CONF contains definitions for the participating trunk lines and "stations" (i.e. extensions) within your system. The trunk definitions have "type=trunk" and the extensions have "type=station". Each definition starts with a name tag in square brackets. The names you use for the entities in SLA.CONF are arbitrary, but in general you should choose short meaningful names (the names you use here must later be matched to entries you will be adding within the dial plan and when configuring your IP phones - hence the choices you make here are important). The convention in nearly all the examples I have seen is to call the trunk objects "line1", "line2" etc. The name tags you use for the stations should clearly describe the extension they refer to, avoiding any possibility of ambiguity. The convention adopted by the author and used in all the examples here is to prefix the actual extension number with 8*. For example, extension 4001 is given the name tag "8*4001" and 4002 becomes "8*4002". This convention has been chosen for sound reasons - firstly, it is important to avoid using just the extension number alone because this could lead to ambiguity in the dial plan. The choice of "8*" is based on the following: 1. 2. 3. 4. It is easy to read and see the actual extension number because * provides a visual break It is unlikely that a user would accidentally dial 8* from their phone It is known to work correctly on the IP phones tested (some prefixes did not) It is tested and known to correctly match number patterns such as "_8*40." in the dial plan. Some other prefixes we tried did not.

Devices The device parameter has a different role in trunks than it has in stations. For the trunks, it tells Asterisk how to get access to the relevant trunk line when the user wants to make a call. For the stations, it tells Asterisk what device to ring when an inbound call arrives on a trunk. For greatest flexibility, we recommend that you set the trunk device to "Local" with a start point in your dial plan similar to the example below.

Configuring a trunk line

Here is an example section from SLA.CONF showing the parameters used to define trunk line 1. [line1] type=trunk device=Local/sla@line1-out ringtimeout=14 barge=yes hold=open

Device The device parameter tells Asterisk what to do when a user presses the programmed key on their phone to seize a trunk line and make an outbound call. If you are using Zap ports for the trunks, then Asterisk will recognise a definition such as "device=Zap/1". However, if you want to use non-Zap ports then you should use a setting such as the one shown in the above example. By using "Local" followed by a start point in extensions.conf, you can control how Asterisk seizes the line. The start point in our example would be in the context [line1-out] at priority 1 of the section defined for extension "sla". A line such as this: [line1-out] exten => sla,1,Disa(no-password|fxo-out)

The dial plan associated with dialling and making outbound calls is explained in more detail later here. Ringtimeout The ringtimeout parameter determines for how long (in secoonds) an incoming call should ring before the SLATrunk function returns with a RINGTIMEOUT result. For more details see the explanation for the SLATrunk function below. Barge The barge parameter determines whether other extensions are permitted to join an existing call in a conference by

The barge parameter determines whether other extensions are permitted to join an existing call in a conference by pressing their shared line key. If extension A answers the call on line 1, the lamp for line 1 will be lit on all the other participating extensions. At this point, if a user at extension B presses the key for line 1, they will become conferenced with the existing call. Setting "barge=no" would prevent this from happening. The default setting is "yes". Hold The hold parameter determines whether a call placed on hold by a particular extension can be retrieved from hold by other stations. It takes one of two values: "open" or "private". The default option is "open", meaning that any other extension participating in SLA can retrieve a call that has been put on hold. The alternative, "private", means that only the extension that put the call on hold is allowed to retrieve it.

Configuring an extension or "Station"

Here is an example section from SLA.CONF showing the parameters used to define extension 4001. [8*4001] ; Grandstream GXP2000 type=station device=SIP/4001 ringdelay=0 ringtimeout=30 trunk=line1 trunk=line2

Device The device parameter tells Asterisk which device to ring when an incoming call arrives on an associated trunk line. In the example shown above, we have said that SIP extension 4001 should ring immediately any call arrives on line1 or line2. It is permitted to have many "station" entities participating in SLA thereby allowing multiple extensions to ring simultaneously when an incoming call arrives. Ringdelay The ringdelay parameter determines a delay (in seconds) before this extension should start ringing. The timer starts when the SLATrunk function is called from within the dial plan. You can set different ringdelay values against each trunk line if you want - this option allows quite complex ringing patterns to be programmed for different trunks and different extension phones. Ringtimeout The ringtimeout parameter determines how long the ringing should last at this station. You can set different ringtimeout values against each trunk line if you want - this option, when used in conjunction with ringdelay, allows quite complex ringing patterns to be programmed such as delivering a splash ring on secondary extensions if an incoming call has not been answered within, say, 20 seconds. Trunk The trunk parameter tells Asterisk which trunk lines are presented at this extension. What do I mean by "presented"? It means two things - first it defines for which trunks this phone should ring (i.e. when an incoming call arrives on the trunk); second, it tells Asterisk to expect that this extension phone has got programmed keys assigned to those trunk lines. Asterisk will maintain an array of internal states for the shared line keys it knows are on the phone and will accept SUBSCRIBE requests that are mapped to those line states from the phone. Tip: Although it is not stated in the developer's documentation, it does not actually matter if the phone doesn't have any programmed keys assigned. This means you could, for example, make an analogue extension be part of the ring group. It would not have any shared line keys so you would not get a lamp showing line activity and it would be difficult for the phone to participate in other SLA features like call transfer, but it would ring and could therefore answer incoming calls.

Configuring the Aastra 53i Phone for SLA

Configuring the Global SIP Account
SIP Accounts are configured under the Advanced Settings section of the web admin page. In our example, the Aastra is linked to a pre-defined user account in Asterisk - username and extension number are both set to 4003. Using the web interface, login as admin then select Advanced Settings|Global SIP On this page you should program default settings for SIP registration and the addresses and port numbers for the various SIP servers (Proxy, Outbound Proxy and Registrar). These will usually all be set to point to your Asterisk server - probably using the default SIP port of 5060. Note that Line Mode is left as "Generic".

Click to view sample.

Configuring SIP Accounts for Lines

The Aastra-53i allows accounts to be created for up to 9 lines, although only the first three have line keys on the phone set. If you want, you can associate a different SIP user account with each line. Furthermore, under Preferences, there is an option to set which line account is the preferred one. However, if you don't have a specific need for multiple accounts, keep things simple and for line 1 just use the same login details already given in your Global SIP account. Lines 2 to 9, just leave blank. Using the web interface, login as admin then select Advanced Settings|Line 1 To use the default settings from the Global SIP account, you can leave various fields with their default values. For example, Server addresses can be left as 0.0.0.0 and port numbers can be left as 0. The Global defaults are then used. However, if you enter new data into some of the fields for Caller ID, Authentication and Password, then it is best to enter values for all of these fields. Leave Line Mode set to "Generic".

Click to view sample.

Configuring the Programmable Keys

Using the web interface, login as admin then select Operation|Programmable Keys Using the drop-down selector, set Type to BLF. Value must be set to a combination of the name tags used in SLA.CONF to describe the station and the line (linked by the underscore character). For example, if the station is referred to as 8*4001 in SLA.CONF and each trunk line was named line1, line2, etc, then Value would be set to: 8*4001_line1 8*4001_line2 etc. Line is used to select one of the phone's lines. If the Global SIP account is used for this purpose then you can set Line to global.

Click to view sample.

Configuring the Grandstream GXP2000 Phone for SLA

Using the web interface, login as admin then select BASIC SETTINGS Scroll down to the section where the "Multi Purpose Keys" are defined. Using the drop-down selector, set Key Mode to Busy Lamp Field (BLF). UserID must be set to a combination of the name tags used in SLA.CONF to describe the station and the line (linked by the underscore character). For example, if the station is referred to as 8*4001 in SLA.CONF and each trunk line was named line1, line2, etc, then UserID would be set to: 8*4001_line1 8*4001_line2 etc. The box labled Name is used to display information on the LCD screen and you should enter a short text description such as "Trunk Line 1" or "Shared Line 1" or whatever you want. Account is used to select a SIP user account. It should be the account the phone uses to register with Asterisk.

EXTENSIONS.CONF: Setting the Hints used by SLA

The SIP SUBSCRIBE/NOTIFY mechanism - what it is and how it works The SIP protocol includes a standardised mechanism to allow any SIP client (an IP phone being an example of a SIP client) to monitor the state of another device. Details are provided in the SIP protocol document RFC3265. Basically, it works like this: If client device A wants to be informed of changes to the status of device B, it sends a SUBSCRIBE request - either directly to device B or to a server that is aware of the state of device B. If the SUBSCRIBE request is successful, then every time device B changes state, device A is sent a SIP NOTIFY message telling it about the event or change of status. This is the mechanism that IP phones use to control BLF lamps. It is the mechanism that Asterisk SLA uses to switch on and switch off the trunk status lamps on participating extension phones. (By the way, it is also the same mechanism that is used to switch on/switch off message waiting lamps). Hints - How Asterisk supports the SUBSCRIBE/NOTIFY mechanism Asterisk is like a PBX - it acts as a SIP server and it has awareness of the state of many things including attached phones, queues, voicemail boxes etc. It makes perfect sense that Asterisk should be able to accept SUBSCRIBE requests and then notify the subscribing device whenever there is a change of status in the monitored device. However, the SIP protocols and standards cannot pre-define a name for every possible device or status - instead, the protocol provides a general framework for event notification without defining the actual events or device names. To allow maximum flexibility, Asterisk allows device names to be configured within the dial plan - within the extensions.conf file. For this purpose it uses something called Hints. Hints are simply a user-configurable mapping between an arbitrary

file. For this purpose it uses something called Hints. Hints are simply a user-configurable mapping between an arbitrary name tag and a specific telephony device or application that Asterisk knows about. When Asterisk receives a SIP SUBSCRIBE request it checks for a hint in the dial plan that matches the name of the device to be monitored. The hint tells Asterisk which physical device this corresponds to. It is best understood by seeing some examples. Some examples of Asterisk Hints Hints usually map an extension number (or name) to a device. However, hints can also map to other special internal states (virtual devices) such as the state of a specific call park slot or the state of a specific meetme conference. SLA introduces a new virtual device that is used in a hint to allow subscriptions to the state of a trunk line as defined in the SLA.CONF file. Here are some examples of Asterisk hints: [mysubscribes] exten => 4001,hint,SIP/4001 exten => 2001,hint,Zap/5 exten => parked01,hint,park:701@parkedcalls exten => 6555,hint,Meetme:555 exten => 8*4001_line1,hint,SLA:8*4001_line1 exten => 8*4001_line2,hint,SLA:8*4001_line2

Hints used for Asterisk SLA Note particularly the last two lines in the above example. These hint lines are used to map the tag "8*4001_line1" to the state of the virtual device "SLA:8*4001_line1" and the tag "8*4001_line2" to the state of the virtual device "SLA:8*4001_line2". What this means is that a programmable key on an IP phone can now subscribe to the state of "8*4001_line1" and it will then receive updates (in the form of SIP NOTIFY messages) every time the corresponding virtual device changes state. Virtual devices prefixed with "SLA:" identify elements within the array of internal states mentioned earlier. These internal states are updated when your dial plan calls the functions SLATrunk or SLAStation or when a call on one of those trunk lines ends. At this point, all the subscribing phones are sent a NOTIFY message to tell them the new state. For Asterisk SLA to work properly, you must define appropriate hints for all the programmable keys assigned as shared line keys on your IP phones. If you had 4 trunk lines and 10 IP phones using SLA then this might mean you need to define a total of 40 hints in your dial plan! This is where the use of "autocontext" looks like an attractive option - it automatically creates the hints for you. However, there is a major downside to using autocontext for this purpose - any subsequent reload of the dial plan will erase all the auto-created hints. Therefore, you are advised to grit your teeth and just add all 40 hints manually. Unfortunately, you cannot use exten number patterns and the ${EXTEN} variable for hints - Asterisk checks if the hint device exists when the dial plan is first read so it throws errors up for hints that try to use variables. Where does Asterisk look for the hints in extensions.conf? To avoid any possible confusion about the location of these hints, it is recommended that you use the subscribecontext parameter in your sip.conf file to identify the location of all hints within extensions.conf. There is a little documentation about subscribecontext within the Asterisk wiki:

http://www.voip-info.org/wiki-Asterisk+config+sip.conf
You may find the examples in this link slightly more useful:

http://www.voip-info.org/wiki/view/480i+Busy+lamp+field+'BLF'+support

EXTENSIONS.CONF: Dial plan for Inbound calls using SLA

Dial plan for Inbound calls on Trunk Lines Central to the correct handling of inbound calls is the function SLATrunk. Essentially, if a call comes in on trunk line 1 then you must call SLATrunk(line1). If a call arrives on trunk line 2, then you must call SLATrunk(line2). The parameter you pass to the SLATrunk function must be the name tag you assigned to that trunk in SLA.CONF. Systems with SIP trunks are far less suited to SLA than those using conventional analogue trunks, so in this section we mostly concentrate on the use of analogue trunk lines. These might be Zap FXO ports or, if you are using the Pika Warp Appliance, they would be Pika FXO ports. If you are only using one FXO port then the dial plan is straightforward, but on systems with more than one trunk line some method must be used that ensures the correct parameter value is passed to function SLATrunk. There are two ways this can be done: 1. Assign each trunk line to its own unique context within the zapata.conf or pika.conf file. In this case, autocontext may be used to automatically generate the required entries in the dial plan. 2. Assign all trunks to a common inbound call handling context. Within that context, extract the FXO port number from the channel variable ${CHANNEL}. Autocontext is not suitable for use with this method. The following example shows how to call the SLATrunk function within a dial plan context that is common to all the FXO

The following example shows how to call the SLATrunk function within a dial plan context that is common to all the FXO ports, using a variable whose value is set from the ${CHANNEL} variable. (This sample code would only be suitable for a maximum of 9 FXO ports!): [fxo] exten => s,1,Noop('Channel ID is '${CHANNEL}) exten => s,n,Set(linetag=line${CHANNEL:-1}) exten => s,n,SLATrunk(${linetag}) exten => s,n,Noop('SLATrunk status is '${SLATRUNK_STATUS}) exten => s,n,Gotoif($[${SLATRUNK_STATUS} = SUCCESS] ?exit) exten => s,n,Answer() exten => s,n,Wait(1) exten => s,n,Background(greeting1) ..... here the dial plan depends on call handling choices and so is not shown exten => s,n(exit),Hangup

Explanation for the above example dial plan: The variable ${CHANNEL} is pre-set by Asterisk to show the channel. On a Pika Appliance, it might look like this "Pika/fxo/1" for FXO port 1 etc. ${CHANNEL:-1} gets only the last character from that variable - the channel number. The variable "linetag" is created by the Set function and given a value of "line1" for FXO port 1, "line2" for FXO port 2 etc. The call to SLATrunk uses this variable as its parameter. The function SLATrunk will eventually return and the dial plan will then execute the next step. We can check the outcome of the SLATrunk function using the variable ${SLATRUNK_STATUS} - it is a kind of return code. A value of "SUCCESS" indicates that the call was answered within SLATrunk so our dial plan does not need to do anything more. Any other return value shows that the call has not been answered, so we may want Asterisk to answer it and play a greeting then do further processing such as record a voicemail message or whatever. Answering an incoming call There are actually two ways that a user can answer an incoming call using SLA: 1. If their phone is ringing, they can pick up the handset (or press the speaker phone button). 2. If a shared line key is correctly programmed for the relevant trunk line, then the lamp will be flashing to show there is an incoming call - the user can press that shared line key to answer the call. It is possible for a phone to ring and have no shared line key. It is also possible for a phone to be showing the incoming call on a shared line key, but to not be ringing (for example, when the station "ringdelay" parameter in sla.conf has a non-zero value). It is also possible for a phone to ring and show the incoming call on a shared line key at the same time. These things are all controlled by settings in SLA.CONF.

Asterisk function SLATrunk()

The SLATrunk function must be called in the dial plan whenever an inbound call arrives on the trunk line. Its behaviour depends on what it believes the current line status to be, but generally it will ring the associated stations according to the ring rules defined in the station definitions in SLA.CONF. This function is responsible for updating all the Stations that are subscribed for information about the line status of the selected line (using a SIP NOTIFY request). You pass it the name label that identifies the trunk line. For example: SLATrunk(line2) If the function is called for a trunk line that Asterisk believes is already active, it will return immediately to the next step in the dial plan and the channel variable "SLATRUNK_STATUS" will be set to "FAILURE". If the function is called for a trunk line that it believes to be idle, then it will ring the various stations as configured in SLA.CONF until either the call is answered or the ring timeout (as defined in SLA.CONF) is reached. The channel variable SLATRUNK_STATUS will then have one of the following values: SUCCESS or RINGTIMEOUT.

EXTENSIONS.CONF: Dial plan for Outbound calls using SLA

What's the problem?
The section of your dial plan that handles outbound calls has to be a bit clever. This is because there are several different cases that need to be hand led correctly, yet they are all initially sent to the same section of the dial plan. It has to cope with internal calls and calls to PSTN numbers; recognise on-hook and off-hook dialling; recognise when the user has selected a specific outside line and when they simply want any available outside line; it also is this section that has to recognise and correctly handle other requests made using the shared line keys - for example, when the user wants to pick up or conference into an existing call on one of the shared lines. Incidentally, Caller ID adds yet more complexity if, for some reason, you would like different trunk lines to use different caller ID's. Fortunately, this tends not to be an issue on analogue trunks, but could be relevant when using SLA in combination with SIP trunk connections (or especially with a mixture of analogue and SIP trunks).

Which section of the dial plan is relevant for outbound call handling

Which section of the dial plan is relevant for outbound call handling
When the user of an IP phone makes a call, the section of the dial plan that handles it is normally defined by the "context" parameter given in your SIP.CONF file. There may be a default context that applies to every SIP peer, but it is recommended that an explicit context is given, as shown in the following example: Definition for IP Phones 4001 and 4003 within file SIP.CONF [4001] type = friend username = 4001 callerid = "Grandstream GXP2000" <4001> secret = 123 host = dynamic context = sip-out subscribecontext = mysubscribes qualify = no call-limit=4 disallow = all allow = alaw allow = ulaw [4003] type = friend username = 4003 callerid = "Aastra 53i" <4003> secret = 123 host = dynamic context = sip-out subscribecontext = mysubscribes qualify = no call-limit=4 disallow = all allow = alaw allow = ulaw

It is also possible that a domain specific context has been defined, in which case this setting may over-ride the explicit setting for the peer. It is important to get this right for correct sla operation so you should confirm which context is being used when the IP phone makes a call: Try increasing the "verbose" level to 3 and making a call from the IP phone, then check which context was used. The console output will show something like "Executing [number@context] ..." From the Asterisk CLI (Command Line Interface) type the command "sip show users". Look for the context name in the column "Def.Context". However, be aware that this setting will be trumped by a different setting for the domain that the phone is registered on. You can see domain specific context settings by typing "sip show domains" at the CLI prompt and looking at the column called "Context". Once you are sure that calls from extension 4001 are being processed in a specific context (in the examples it is called "sip-out"), then it is ok to proceed to the next step.

Cases that must be handled in your dial plan

A new INVITE will be generated when the user presses one of the shared line keys, but one will also be generated when they dial a number. That doesn't sound too complicated, but when you consider how different people may use a phone (or the same person at different times) then you can see that there is potential for complexity. Concentrating on the options that need to be considered for Aastra phones, the list looks like this: Press a shared line key, get dial tone, dial an external (PSTN) number Pick up handset (or press speaker phone button), get dial tone, dial number Press a line key, get dial tone, dial number Dial a number (off-hook dialling), press a line key Dial a number (off-hook dialling), press the Dial soft key There are other cases (not shown above) that simply are not allowed - they will not work. In particular, you cannot dial the number then press a shared line key to make a call on a specific trunk line. Also, it would not make any sense to press a shared line key, get dial tone, then dial an internal number - you have selected a trunk line so you cannot now make a call to another extension!

On-hook dialling and use of the phone's own line keys

Whether or not it makes a difference to dial the number first, then press the line key (as opposed to pressing the line key, then dialling the number) will depend on how you have programmed your IP phone. You may want to configure the line keys with an auto-dial number to make them behave a bit like the shared line keys. I have seen this suggested in some of the documentation for SLA and it could be useful if your users are confused by the difference between shared line keys (that use the programmable keys on the phone) and the phone's own line keys. It would hardly be surprising if users did find this confusing.

if users did find this confusing. If you program the phone's own line keys to auto-dial an SLA name tag, then you can make them behave the same as the shared line keys, but only for a limited set of cases. Auto-dial is available on the Aastra and the adjacent screen shot shows how you might want to make use of this feature with SLA.

Click to view the entire setup page

Other line keys would need to use SLA name tags that were appropriate for their line number. For example, line 2 would be set to auto-dial "8*4003_line2" etc. Unfortunately, the Grandstream GXP2000 does not seem to provide an auto-dial facility, but if anyone knows better, please contact me.

How do we handle the different cases in the dial plan?

Assuming you are using the Aastra phone with the auto-dial feature enabled, as discussed above, the dial plan will now need to be able to handle the following: 1. 2. 3. 4. 5. Press a shared line key: a specific trunk line is seized, user hears dial tone and dials external number Press a phone line key: a specific trunk line is seized, user hears dial tone and dials external number Pick up handset (or press the speaker button): user hears dial tone and dials an internal number User dials an internal number (another extension) and presses a phone line key User dials an internal number (another extension) and presses the Dial soft key

The following cases are deliberately omitted from the list at this point because they cannot be handled correctly when autocontext is used. Techniques for handling them are discussed later: Pick up handset (or press the speaker button): user hears dial tone and dials an external number User dials a PSTN (external) number and presses a phone line key to make the call User dials a PSTN (external) number and presses the Dial soft key Fortunately, several of the five cases described above will look exactly the same once they reach Asterisk, so the dial plan is a lot less complicated than you might expect. By the way, it is assumed in this example that you have assigned the same user account to all the auto-dial lines. Cases 1 and 2 will produce identical interactions with Asterisk. Assuming the same internal number is called, cases 3, 4 and 5 will all result in an identical INVITE being sent to Asterisk. So really, there are just two different cases that must be handled. Not so bad after all. Without autocontext: The dial plan to handle all this could be manually constructed as follows: Dial plan snippet from EXTENSIONS.CONF [sip-out] ; User pressed a shared line key and will be presented with dial tone exten => 8*4001_line1,1,SLAStation(8*4001_line1) exten => 8*4001_line2,1,SLAStation(8*4001_line2) exten => 8*4003_line1,1,SLAStation(8*4003_line1) exten => 8*4003_line2,1,SLAStation(8*4003_line2) ; User dialled an internal extension (4 digit number starting with 4) exten => _4XXX,1,Dial(SIP/${EXTEN},26) exten => _4XXX,n,VoiceMail(${EXTEN}@other,b) exten => _4XXX,n,Congestion(5)

With autocontext: If you were using autocontext for the stations, then the four lines of the dial plan that call the SLAStation function would be generated automatically, so you could simply have a dial plan like this: Dial plan snippet from EXTENSIONS.CONF [sip-out] ; User dialled an internal extension (4 digit number starting with 4) exten => _4XXX,1,Dial(SIP/${EXTEN},26) exten => _4XXX,n,VoiceMail(${EXTEN}@other,b) exten => _4XXX,n,Congestion(5) The section of SLA.CONF that tells Asterisk to use autocontext would look like this: [8*4003] ; Aastra 53i type=station device=SIP/4003 autocontext=sip-out ringdelay=0

ringdelay=0 ringtimeout=30 trunk=line1 trunk=line2

Who is generating the dial tone?

It is important to understand which piece of equipment generates the dial tone heard by the user. In cases 1 and 2, the audible dial tone is coming from Asterisk, but in case 3 the dial tone heard by the user is generated by the IP phone. When the IP phone is generating dial tone, it will send an invite to Asterisk only after the user has finished dialling. In cases 4 and 5, there is no audible dial tone because they are using "on-hook" dialling. When Asterisk has to generate dial tone, it can do it in one of two ways: 1. Using the built-in Asterisk DISA function 2. By taking the physical trunk line device off-hook (only applicable to analogue trunks) If you don't know what DISA is, please click here (opens a pop-up window)

What happens inside Asterisk when a shared line key is pressed? When the key for Shared Line 1 is pressed on the Aastra phone, it causes an INVITE to be sent to Asterisk. The target number of the INVITE will be "8*4003_line1" so it will match the corresponding line in the dial plan and call the command SLAStation(8*4003_line1). What this does depends on what you configured for the "Device" parameter of line1 in SLA.CONF. You may remember that I recommended you to set device like this: device=Local/sla@line1-out By specifying a "Local" device, this actually means that Asterisk will jump to a new position in the dial plan and will start to execute the lines at that position. In the example shown above, it will jump to the context [line1-out] and try to find a step within that context matching the target extension ID - in this case, the target is set to "sla", but it could be almost anything. What you specify in your dial plan depends if you want to use DISA to present dial tone or if you want to take the trunk line off-hook. If it is a SIP trunk, then you have no choice - you must use the DISA function. If it is a Zap port or a Pika FXO port, then you should take it off hook as shown in the examples below: [line1-out] ; The following three blocks show alternatives for shared line 1. ; You would only have one of them in a real dial plan. ; Select the one that matches your trunk's hardware/technology ; For a SIP trunk, use the Asterisk DISA function to generate dial tone exten => sla,1,Disa(no-password|line1-out) ; Take Zap channel 1 off-hook. Assumes that channel 1 is an FXO port exten => sla,1,Dial(Zap/1/) ; Take Pika FXO channel 1 off-hook to allow direct dialling on the trunk exten => sla,1,Dial(PIKA/fxo/1//) ; The following is required only for the Disa mechanism used with a SIP trunk ; Calls to numbers matching PSTN numbers use the SIP trunk exten => _0XXXX.,1,Dial(SIP/${EXTEN}@provider1|50|w) ; Calls to any other number are considered invalid exten => i,1,Playback(invalid) exten => i,n,Hangup Why you should take the FXO trunk line off-hook There is a major advantage in taking the trunk line off-hook as soon as the shared line key is pressed. When you present dial tone this way, there is no risk of an incoming call arriving on the trunk while the user is dialling. If, instead, you were to use the Asterisk DISA function, there would be a significant risk that an inbound call may start ringing the trunk line before the user has finished dialling. This is a situation that you really don't want to allow - it would result in mis-handling of both the inbound and the outbound calls. Another advantage of using the FXO "off-hook" technique is that it requires fewer entries in the dial plan and generally keeps the dial plan simpler.

Improving the dial plan to handle more cases

Using the dial plan described above, your Asterisk system will be able to handle the following dial requests from an Aastra or other suitable IP phone:

Aastra or other suitable IP phone: Select a shared trunk line, hear dial tone, dial external number Pick up handset, hear dial tone, dial an internal number Dial an internal number, press the 'Dial' soft key (or press a phone line key) However, it will fail if the user tries to dial an external number without first selecting one of the shared trunk lines. This would be a very annoying limitation for users - ok, you could regard it as a problem that can be addressed by suitable "user training", but I have seen too many instances of poor equipment design being explained away with the limp excuse that the users just need to be better trained. If a user can dial an external number by pressing the line key then dialling, it is reasonable for them to expect to be able to dial and then press the line key. What you should be aiming for is a consistent and reasonably intelligent user interface - Asterisk is perfectly capable of pattern matching on dialled numbers, so how can we upgrade the dial plan to handle it correctly? Unburden yourself from the chains of "autocontext" Yes, this is the point where you have to abandon "autocontext". We mentioned much earlier that autocontext was probably not worth using and if you want to take Asterisk shared line appearances to the next level, with an improved user experience, then autocontext must be disabled. With autocontext disabled, you can now take advantage of the slightly curious naming convention we recommended for the stations in SLA.CONF. The recommendation was to prefix the extension number with "8*". This was chosen because it allows extension patterns to be used in the dial plan. This means that a single line in the dial plan can now be used for tens or hundreds of different stations and lines. Look for the pattern "_8*." in the samples below.

How can SLAStation offer DISA and also handle pre-dialled numbers?
This is the problem that has to solved - when a user dials a number on the IP phone, it sends an INVITE to Asterisk that must be handled in one specific dial plan context. However, depending on how the user dialled the number you may want the dial plan to do any one of the following three things: 1. Use the Dial command to call an internal number - no shared trunk line is required 2. Use the SLAStation command to select a specific shared trunk line, present dial tone to the user and then wait for the user to dial an external number 3. Use the SLAStation command to select any available shared trunk line, then immediately place a call on that shared trunk line using a pre-dialled number Our previous examples for the dial plan would not be able to handle the last of those three cases and it is not immediately obvious how you can use SLAStation to perform two different jobs. The trick that must be used is to set a variable before calling SLAStation and then make the dial plan inspect the variable just after SLAStation has been called. We have also made an assumption that the Caller ID number of the IP phone that is making the call is preset to the correct extension number of that device. This data is then used as part of the parameter passed to the SLAStation function. If your IP phones are not configured with their extension number as the caller ID, then you would have to find some other way of identifying which extension is making the call and ensuring that the correct parameter is passed to SLAStation. The code for the dial plan now looks like this: [sip-out] ; User pressed a shared line key and will be presented with dial tone exten => _8*.,1,Set(_MYDATA=disa) exten => _8*.,n,SLAStation(${EXTEN}) ; User dialled an internal extension (4 digit number starting with 4) exten => _4XXX,1,Dial(SIP/${EXTEN},26) exten => _4XXX,n,VoiceMail(${EXTEN}@other,b) exten => _4XXX,n,Congestion(5) ; User dialled an external number - grab any free shared trunk line exten => _0XXXX.,1,Set((_MYDATA=${EXTEN}) exten => _0XXXX.,n,SLAStation(8*${CALLERID(num)}) ; Handle unrecognised number dialled exten => i,1,Answer() exten => i,2,Playback(invalid) exten => i,3,Hangup [line1-out] ; this context is used to process outbound calls on shared line 1 (Zap FXO) exten => sla,1,Gotoif($[${MYDATA} = disa] ?disa:data) ; disa - wait for caller to dial a number (presents trunk dial tone as prompt) exten => sla,n(disa),Dial(Zap/1/) exten => sla,n,Hangup ; data - user has already dialled a number and SLAStation has selected this line exten => sla,n(data),Dial(Zap/1/${MYDATA},40) exten => sla,n,Congestion(5) [line2-out] ; this context is used to process outbound calls on shared line 2 (Pika FXO) exten => sla,1,Gotoif($[${MYDATA} = disa] ?disa:data)

exten => sla,1,Gotoif($[${MYDATA} = disa] ?disa:data) ; disa - wait for caller to dial a number (presents trunk dial tone as prompt) exten => sla,n(disa),Dial(Pika/FXO/2//) exten => sla,n,Hangup ; data - user has already dialled a number and SLAStation has selected this line exten => sla,n(data),Dial(Pika/FXO/2/${MYDATA},40) exten => sla,n,Congestion(5) [line3-out] ; this context is used to process outbound calls on shared line 3 (SIP Provider1) exten => sla,1,Gotoif($[${MYDATA} = disa] ?disa:data) ; disa - wait for caller to dial a number (presents dial tone as prompt) exten => sla,n(disa),Disa(no-password,line3-out) exten => sla,n,Hangup ; data - user has already dialled a number and SLAStation has selected this line exten => sla,n(data),Dial(SIP/${MYDATA}@provider1,40,w) exten => sla,n,Congestion(5) ; handle the results from the Asterisk Disa function ; User dialled an external number exten => _0XXXX.,1,Dial(SIP/${EXTEN}@provider1,40,w) ; All other dialled number patterns are considered invalid exten => i,1,Playback(invalid) exten => i,n,Hangup

Explanation for the above example dial plan: The variable ${MYDATA} is set before the SLAStation function is called and can be inspected and used by the part of the dial plan that executes after SLAStation is called. Note that you must prefix the variable name with the underscore character when you set it - this tells Asterisk to make the variable available to child processes spawned from the original thread that was handing the call. Inside the [line1-out] and [line2-out] contexts the variable is tested. If it has been set to "disa" then the trunk is taken offhook using the appropriate parameter in the Dial command. Otherwise the variable is assumed to contain the pre-dialled number and a call is placed on the line using the stored number. Inside the [line3-out] context the variable is tested. If it has been set to "disa" then the Asterisk DISA function is called, but otherwise it is assumed to contain the pre-dialled number and a call is placed on the SIP line using the stored number. Extra dial plan code is required in this context to handle the results from the Asterisk Disa function - only calls to external numbers are permitted using Disa because the SLA mechanism has already allocated the trunk line.

Asterisk function SLAStation()

The SLAStation function must be called in the dial plan whenever the Programmed Key on the IP phone is pressed. It effectively seizes a Trunk Line on behalf of the Station that made the request, but its exact behaviour depends if the line is already in use. It is responsible for updating all the Stations that are subscribed for information about the line status of the selected line (using a SIP NOTIFY request). You pass it the name label combination that identifies which key was pressed. For example: exten => 8*4001_line2,1,SLAStation(8*4001_line2) You can also pass it a name label that only identifies the IP Phone, in which case Asterisk will check each of the associated lines in sequence until it finds one that is free. This is recommended as a mechanism for general purpose dialling from your IP phone, such as when the phone is taken off-hook. exten => 8*4001_call,1,SLAStation(8*4001) If the function is called for a specific line and that line is idle, then the line is marked as "in-use" and is effectively reserved for that Station's use. If the function is called for a specific line and the line is ringing, then it does a pickup of the ringing line. If the function is called for a specific line and the line is already "in-use" then the Station that initiated the request will join the call in a conference (it uses meetme).

What is good and what is bad about the Asterisk implementation of SLA?
Benefits of Asterisk Shared Line Appearances
Replacement of legacy systems: The main reason for wanting to configure Shared Line Appearances in Asterisk is because the Asterisk system is replacing a traditional key and lamp telephone system. However, this is certainly not the only reason for using SLA.

Visual representation of call activity: SLA provides users with clear visual indications of call activity and, given enough programmable keys on the IP phones, you could have a key/lamp for every trunk line and every extension on your system. Where the system size is too large you would be able to use an expansion module such as the Grandstream GXP-2000EXT. Highly configurable ring groups: SLA offers a rich combination of options for including and excluding different "stations", assigning different ring delays and ring durations. In some ways it offers a superior set of features for configuring ring groups/pickup groups than the native features of Asterisk.

Imperfections and weaknesses of Asterisk Shared Line Appearances

It should be pointed out that some of the weaknesses of SLA mentioned here are inherent in the original mechanism that was used with key telephone systems. They are included in my "bad features" list simply because they stand out when seen in the context of Asterisk and modern IP phones that are not using SLA. If you are already familiar with the call handling mechanisms and features available on a good IP phone connected to Asterisk, then the loss of some of the nicer serviceability features is quite frustrating. Conventional call transfers are no longer possible: Probably the most annoying aspect of SLA is the fact that call transfers are handled in a way that is completely different to transfers for other calls. Any attempt to use the Transfer or Hold button on your IP phone will result in the call being "parked" on the Asterisk system and disconnected from the IP phone. This means that while you are trying to transfer the call, your IP phone no longer has any direct connectivity with the call on the shared trunk line (the call that is on hold) - you cannot therefore simply toggle between two calls by pressing the relevant line key as you would with calls that were not using SLA. You do not see a slow blinking line button on the Snom 360 to show you that one of your callers is on hold (as you do without SLA). You cannot complete an attended transfer by hanging up or by pressing the transfer button as you might without SLA. You cannot do blind transfers at all. Instead, SLA calls are transferred by putting the caller on hold, calling or telling the other user to "pick up the call on line X" and hoping that they will press the correct shared line key on their phone. For users this is potentially confusing because internal and external calls are not tranferred in the same way. However, in practice it is unlikely that a user would need to transfer an internal call so they may not even be aware of this difference. Please note - when I say "parked", this does not mean that the Asterisk park mechanism is used. What I mean is that the caller is put on hold on the Asterisk PBX, played music-on-hold, and is no longer associated with any particular extension. Timing: If two users both try to answer the same inbound call there is a good chance that they will end up in a 3-way conference. In a similar way, you might want to make an outbound call so you press the shared line button for a line that you thought was free, but just as you go to press it an inbound call hits the same line. Instead of getting dial tone you find that you have answered the inbound call. IP Phones are not designed for this: SLA uses up your precious allowance of programmable keys. On some phones there are not very many and you need at least some of them for other jobs. For example, the same keys are used for the BLF function when you want to be able to see the state of a colleagues extensions. The IP phone may not behave exactly as you would like it to for SLA. For example, the Grandstream GXP2000 sends a different INVITE when the lamp is flashing (incoming call ringing on line) than it does when the lamp is off (no call on line) or when the lamp is on continuously (line in use). Another example - the IP phones we tested do not put the call on hold if you press the shared line key after you have answered an inbound call. Instead, you must press the Hold button. The fact that different makes of IP phone will behave slightly differently when used for SLA is unfortunate but unavoidable. Another consequence of using generic IP phones for Asterisk shared line appearances is the occassional appearance of inappropriate data on the phone's display. This is explained in more detail in the next two sub-sections below: Caller ID on inbound calls: Getting the Caller ID information to be correct in all possible contexts can be quite a problem for Asterisk SLA. There is no problem getting the caller's number to display on the ringing extension phones for an inbound call, but the moment you press a shared trunk line key (one of the programmable keys on the IP phone) to answer the call, the phone's display ceases to show you information about the caller. Instead it shows you the dial string programmed against that key - something that generally looks like gobbledygook. Using the Grandstream GXP2000 you can set a name string against each key as well as the number - both appear on the display so at least you can see a description such as "Trunk line 1". However, the Aastra does not have this additional name field so all you see is the gobbledygook. The same problem occurs when a call is transferred. The display on the phone shows you the number programmed for that key and not the name or number of the caller you are now talking to. Display of dialled number on outbound calls: When dialling outbound calls on a specific shared trunk line, you get the same problem with the display on the phone as mentioned above for inbound calls. i.e. it shows you the number programmed against the key and not the number you are dialling. Phones in ring group show missed calls: Suppose you have 3 extensions phones (stations) in a ring group for shared line 1 - phones A, B and C. When an incoming call arrives on line 1, all three phones ring. Suppose the user at phone A

answers the call. Now phones B and C will both report a missed call. What makes this even more annoying is that even phone A can report it as a missed call if you pressed the shared line key to answer the call! No call progress heard after dialling with DISA: If you set the dial plan to use the Asterisk DISA function as described in earlier examples on this web page, you will find that there is no audible feedback of call progress after you dial. The DISA function sends dial tone before you dial, but after you dial it just goes silent until the call is answered. Digium said that this had been fixed in a later release. There is no reload option for SLA.CONF: Any changes that you make to the SLA.CONF file will have no effect until you restart Asterisk. Again, Digium said that this problem had been addressed in a later release. Subscriptions are not persistent: Following on from the previous point, after you have restarted Asterisk you will now have to reboot all the IP phones. This is because Asterisk does not remember the subscriptions through a restart without the subscriptions you will find that the lamps on the shared line keys do not come on during call activity. SLATrunk function sets line state to idle on exit: This is a bit of a technical gripe, but is relevant if you use the sample dial plans shown earlier on this web page. The dial plan to handle inbound calls can perform a twofold function (provided autocontext is not used): First it can make a bunch of extension phones ring, but then - if none of those phones is answered - it can perform further processing of the inbound call. For example, it could send the call to voicemail. However, there is a problem - the status lamps for the shared trunk line will show the line as idle while it is actually still in use. This is because the subscribe/notify status for the line gets reset to idle as soon as the next step in the dial plan is executed after the line that executed SLATrunk. It would be preferable if the status remained as "inuse" until the trunk line hangs up. It should be possible to find a work around for this using Asterisk version 1.6 software.

Note: The information in this article is essentially original material prepared by the author following his own detailed investigations which involved a search through existing documentation (both online and comments included within the sample conf files) and practical tests using Asterisk 1.4.14 running on a Pika Warp Appliance with an Aastra 53i IP phone and Grandstream GXP2000 (among others). It is freely offered as guidance and advice for other Asterisk users who may have found the documentation of SLA somewhat lacking. The author cannot accept responsibility for any errors or omissions within this article, but if you want to send feedback to info at smartvox.co.uk please do so and I will do my best to incorporate any suggestions or correct any errors. The text of this article is copyright 2008, 2009 Smartvox Limited. Do not copy this text or any substantive part of it to other web sites or documents. If you want to refer to it please use a link. Last updated on Wednesday 14th January 2009. Products and Services | Support | Contact Us | Home | Affiliates