| 49.6. Busy Lamp Field (BLF) | ||
|---|---|---|
 | Chapter 49. SIP - Session Initiation Protocol |  |
| 49.6. Busy Lamp Field (BLF) | ||
|---|---|---|
| | Chapter 49. SIP - Session Initiation Protocol | |
Advanced SIP phones support a special feature named BLF (Busy Lamp Field). Typically BLF is a collection of lights on a phone that indicate who is talking on other phones connected to the same PBX. The BLF is used by a receptionist or secretary to aid in routing the incoming calls. The lights in telephone commonly have a related button to perform the direct call or the call pick-up.
There is no RFC called "Busy Lamp Field" and actually the lights on the phone are implemented differently by different producers
The most important RFCs related to BLF are:
3856 - A presence Event Package for Session Initiation Protocol (SIP)
4235 - An INVITE-Initiated Dialog Event Package for the Session Initialisation Protocol (SIP)
The lights on the phone may be associated to a lot of different features anyway when speaking about BLF normally there are two options:
Dialog Monitoring (RFC 4235). It is the most used, it displays the state of the calls associated with the Sip extension.
Presence Monitoring (RFC 3856). It is often used by softphones, it display the human state of the user, so if the state is busy it does not mean that he is involved in a call. He is just busy, may be he is reading a newspaper or playing darts. Anyway Asterisk and other similar solutions convert the call state in presence state to satisfy the softphones requests.
Although BLF handling is implementation depended, the following common behaviors may be reported.
In case the IP phone has just one colour led:
Table 49.3. One colour led meaning
| Light state | Dialog monitoring | Presence monitoring |
|---|---|---|
| Off | No current calls | The user is not available |
| Blinking | At least an incoming calls is in alerting state | / |
| On | All the remaining cases (i.e. current calls are connected) | The user is available |
In case of green and red leds:
Table 49.4. Two colours led meaning
| Light state | Dialog monitoring | Presence monitoring |
|---|---|---|
| Off | The subscription failed | The subscription failed or the user is not available. |
| Green On | The subscription was successful and there is no current calls. | The user is available |
| Blinking Red | At least an incoming calls is in alerting state | / |
| Red On | All the remaining cases (i.e. current calls are connected) | The user is busy |
Almost all producers offer modules to increase the number of available leds and buttons for the BLF feature.
In Abilis CPX, the Busy Lamp Field feature is strictly related to OPC (Operator Panel Console), i.e. all what a user can see in OPC is available to BLF, and what is NOT available in OPC is not available in BLF. You should consider BLF as another way to access OPC information.
BLF requires separated licence in CPX and needs also SoftPBX licence as it is required by OPC.
Abilis CPX introduced just a couple of port parameters specific for BLF:
SUB-LIFTIME - Expiration time of incoming subscriptions. Range 60-3600 seconds, default 180.
max-sub - Maximum number of subscriptions that CTISIP may handle independently from the event type, the subscriber and the monitored resource. Range 0-1000, default 100.
There are no new user parameters to handle BLF.
Please refer to OPC driver to configure this service in Abilis CPX.
For a smooth operation of BLF it is necessary that CTIP/CLUS/SIP/IAX interfaces and users have all different numbers assigned. In case that the same number is assigned to a two or more of them the following priority order will be used : CTIP, then CLUS, then SIP, then IAX.
IP phones keys must be properly configured in order to monitor an extension and/or perform call pickup on that extension. There are optional strings that can be used.
Table 49.5. Request URI for Abilis BLF feature
| <number>@domain | The related user is in the local Abilis, the monitored interface is chosen after a search of the <number> in CTIP/CLUS/SIP/IAX interfaces |
| <user>/<number>@domain | The <user> is in local Abilis and the monitored interface is CTISIP. The <number> is needed in case of direct call |
| <interface>/<user>/<number>@domain | The <user> is in local Abilis and the monitored <interface> is specified in the request URI. The <number> is needed in case of direct call |
| <abilisid>/<interface>/<user>/<number>@domain | The <user> may be in a remote Abilis with <abilisid> identifier specified in OPC configuration, the CTI <interface> is specified in the Request Uri. The <number> is needed in case of direct call |
Also note that the SIP user to perform Call Pick-up must have SIP-SS:yes and SIP-SS-PICKUP:ANY.
[19:52:11] ABILIS:d user:test
Parameter: | Value:
--------------------+----------------------------------------------------------
USER: test
...
SIP-SS: YES
SIP-SS-PICKUP: ANY
...
-------------------------------------------------------------------------------About Call pick-up feature also note that there are different handlings in different phones.
Normally the IP phones uses the number provided via SIP signalling (NOTIFY) to perform call pick-up, i.e. it occurs with SNOM and Thomson/Tecnicolor phones.
The Yealink phones default need to specify the number to perform call pick-up in their web interface but they have an advanced option of the Account: Dialog-Info Call Pickup (default is disabled, just enable it) that allow them to use the number provided by SIP signalling.
Finally the Grandstream phones need to specify the call pick-up prefix (default is ** to be changed in *1), and ignores the SIP signalling about call picked up number.
| |  | |
| 49.5. Connecting Abilis and a SIP proxy |  | 49.7. CTISIP diagnostics and statistics |