49.6. Busy Lamp Field (BLF)

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.

Figure 49.2. An IP phone supporting BLF

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.

49.6.1. Dialog an presence monitoring

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.1. 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.2. 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.

49.6.2. BLF in Abilis CPX

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.3. 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 server		49.7. CTISIP diagnostics and statistics