Asterisk SLA (Shared Line Appearances) – Part 4

Link to part 3

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 “in-use” until the trunk line hangs up. It should be possible to find a work around for this using Asterisk version 1.6 software.