49.6. Busy Lamp Field (BLF)

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.8. An IP phone supporting BLF

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:

The lights on the phone may be associated with a lot of different features anyway when speaking about BLF normally there are two options:

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 color led:

Table 49.1. One color led meaning

Light stateDialog monitoringPresence monitoring
OffNo current callsThe user isn't available
BlinkingAt least an incoming calls is in alerting state/
OnAll the remaining cases (i.e. Current calls are connected)The user is available

In case of green and red leds:

Table 49.2. Two colors led meaning

Light stateDialog monitoringPresence monitoring
OffThe subscription failedThe subscription failed or the user isn't available.
Green OnThe subscription was successful and there aren't current calls.The user is available
Blinking RedAt least an incoming calls is in alerting state/
Red OnAll 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 isn't available in BLF. You should consider BLF as another way to access OPC information. The OPC service uses HTTP resource, so OPC users must be enabled to use HTTP. Their HTTP-RIGHTS have to grant access to the /sys/opc/ data directory.


BLF requires a separated licence in CPX and needs also SoftPBX licence as it's required by OPC.

Abilis CPX introduced just a couple of port parameters specific for BLF:

  • SUB-LIFETIME - Expiration time of incoming subscriptions. Range 60-3600 seconds, default 180. The subscription/notification mechanism is used by SIP protocol to get information i.e.:

    • Dialog Monitoring (RFC 4235) is the most used, it provides the state of the calls associated with a SIP extension.

    • Presence Monitoring (RFC 3856) is often used by softphones, it displays 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, maybe he is reading a newspaper or playing darts.

  • 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. If we are handling two SIP phones with BLF and one phone monitors 150 phones and the other monitors 50 phones then max-sub is 150+50=200. If we have 30 phones, and each monitors 20 phones, then we have 600 subscriptions.

There are no new user parameters to handle BLF.

Please refer to the OPC driver to configure this service in Abilis CPX.

For a smooth operation of BLF it's 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>@domainThe 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>@domainThe <user> is in local Abilis and the monitored interface is CTISIP. The <number> is needed in case of direct call.
<interface>/<user>/<number>@domainThe <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>@domainThe <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

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.