The Busy Lamp Field (BLF) – What it is and

how it works (Subscribe, Notify)

Busy Lamp Field (BLF) is a light on an IP phone which

tells you whether another extension connected to the
same PBX is busy or not. This has to be configured
manually from the phone user and it is usually done by
making use of the web interface. When configured, the
phone subscribes to a resource list available on an IP
PBX to be notified with such information about other
extensions. BLF works through the SIP protocol by
making use of SUBSCRIBE and NOTIFY messages. In
a normal scenario, the phone is the subscriber and the IP PBX is the notifier.
How does it work?
When an IP phone is configured to monitor an extension it sends a SUBSCRIBE SIP message to the PBX.
If authentication is configured, authentication takes place and if the subscriber is successfully authenticated
a 200 OK SIP message response is sent back to the subscriber. A NOTIFY SIP message which includes
XML in the message body is sent to the subscriber (in this case the phone) to advise the subscriber the
current state of the extension being monitored. Once status of monitored extension is changed from idle to
busy or vice versa, the subscriber is notified from the PBX with a NOTIFY SIP message. The subscriber
must acknowledge theNOTIFY SIP message by responding back with a 200 OK SIP message. The
subscriber can unsubscribe from this resource by sending a SUBSCRIBE SIP message to the PBX with
Expires header set to 0. The way this works is a three step process.
The Subscribe Process
In this scenario we have a phone that is configured to be registered with a PBX on extension 106. Below is
a sample capture of a SUBSCRIBE SIP message of this phone when subscribing to be notified about the
status of extension 136. Note that the sample has been shortened for documentation purposes.
SUBSCRIBE sip:136@10.130.130.4;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.130.130.58:2051;branch=z9hG4bK-0u81ot32wxh9;rport
From: <sip:106@10.130.130.4>;tag=4fog9tlb9d
To: <sip:136@10.130.130.4;user=phone>
Call-ID:qov573
CSeq: 2 SUBSCRIBE
Max-Forwards: 70
Contact: <sip:106@10.130.130.58:2051;line=1ofdyu7v>;flow-id=1
Event: dialog
Accept: application/dialog-info+xml
Expires: 3600
Content-Length: 0

From the sample above we can see that:

1. SUBSCRIBE sip: 136@10.130.130.4;user=phone SIP/2.0 – The SUBSCRIBE SIP message sent to
monitor extension 136 registered on IP PBX 10.130.130.4.
2. From: <sip: 106@10.130.130.4> – The subscriber, in this case extension 106 registered on IP PBX
10.130.130.4.
3. Accept: application/dialog-info+xml – The application will accept dialog-info which is in XML format.
4. Expires: 3600 – The Expires header, where the duration of the subscription in seconds is stated.
Therefore any time before 3600 seconds pass, the subscriber should send a SUBSCRIBE SIP message
using the same event header and ID parameter to refresh the subscription. Note that the IP PBX server
can reply back with a shorter expiration timeout but cannot lengthen the timeout.
5. Content-Length: 0 – This specifies that there is no XML message body attached to this SIP packet.
Once the SUBSCRIBE SIP message is received from the IP PBX server and successfully processed, a
200 SIP OKmessage is sent back to the subscriber, as shown in the sample below.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.130.130.58:2051;branch=z9hG4bK-0u81ot32wxh9;rport=2051
Contact: <sip:136@10.130.130.4;user=phone>
To: <sip:136@10.130.130.4;user=phone>;tag=9e6f1e0e
From: <sip:106@10.130.130.4>;tag=4fog9tlb9d
Call-ID: 3c491603553e-z27emqqov573
CSeq: 2 SUBSCRIBE
Expires: 3600
Content-Length: 0

The Notify process

The below sample capture shows how the monitored extension changes status. A NOTFIY SIP message
including XML body is sent to the subscriber informing the subscriber of the status of the monitored
extension. Note that the sample has been shortened for documentation purposes.
NOTIFY sip:106@10.130.130.58:2051;line=1ofdyu7v SIP/2.0

Via: SIP/2.0/UDP 10.130.130.4:5060;

Contact: <136@10.130.130.4;user=phone>
To: <sip:106@10.130.130.4>;tag=4fog9tlb9d

From: <sip:136@10.130.130.4;user=phone>;tag=9e6f1e0e

Call-ID: 3c491603553e-z27emqqov573

CSeq: 5 NOTIFY

Content-Type: application/dialog-info+xml

Subscription-State: active;expires=3521

Event: dialog
 Content-Length: 507

<?xml version==”1.0″ encoding=”UTF-8″ ?>

<dialog-info

xmlns=”urn:ietf:params:xml:ns:dialog-info”

entity=”sip:136@10.130.130.4;user=phone”>

<dialog id=”0000145″ call-id=cfd5aad5a5bea3be@10.130.130.42

local-tag=”7ad7d2e7c1f3d62b” direction=”initiator”>

<state>confirmed</state>

<local>

<identity>sip:136@10.130.130.4

<target uri=”sip:117@10.130.130.4″/>

</local>

<remote>

<identity>sip:117@10.130.130.4

<target uri=”sip:117@10.130.130.4″/>

</remote>

</dialog>

</dialog-info>

From the sample above we can see that:

1. NOTIFY sip:106@10.130.130.58:2051;line=1ofdyu7v SIP/2.0 – From this line we can see that this is a
SIP notify message sent to extension 106 which can be found on IP 10.130.130.58.
2. Subscription-State: active;expires=3521 – Here the subscription state and how many seconds are left for
subscription to expire are stated.
3. Content-Length: 507 – The XML message body size in bytes attached to this NOTIFY SIP message.
4. entity=”sip:136@10.130.130.4;user=phone” – The monitored extension is specified in the XML message
body.
5. direction=”initiator” – The monitored extension is starting the call in this example. If the monitored
extension is receiving a call, direction will be set to “recipient”.
6. <state>confirmed</state> – The status of the call, in this example the call has been established. If the
phone is still ringing, state will be set to “early” and if the call is terminated the sate will be set to “void”.
7. in <remote>, <target uri=”sip:117@10.130.130.4″/> – The remote SIP entity to which extension 136 is
calling, in this example extension 117. If the monitored extension is receiving the call, the remote
extension would be the caller.
Once the NOTIFY SIP message is received from the subscriber, the subscriber sends back a 200 OK SIP
message to the notifier as shown in the sample below.
SIP/2.0 200 Ok

Via: SIP/2.0/UDP 10.130.130.4:5060;branch=z9hG4bK-d87543-1–

d87543-;rport=5060

From: <sip:117@10.130.130.4;user=phone>;tag=293c7668

To: <sip:106@10.130.130.4>;tag=mbkzgdctp5

Call-ID: 3c4916034968-2luuodukzci4

CSeq: 5 NOTIFY

Content-Length: 0

The Unsubscribe process

Below is a sample SUBSCRIBE SIP message sent from the subscriber to the notifier to unsubscribe from
the resource. The only difference between a SUBSCRIBE and UNSUBSCRIBE SIP message is that when
unsubscribing the Expire header is set to 0.
SUBSCRIBE sip:136@10.130.130.4;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.130.130.58:2051;branch=z9hG4bK-dg2jd5f8nd0p;rport
From: <sip:106@10.130.130.4>;tag=4fog9tlb9d
To: <sip:136@10.130.130.4;user=phone>;tag=9e6f1e0e
Call-ID: 3c491603553e-z27emqqov573
CSeq: 4 SUBSCRIBE
Max-Forwards: 70
Contact: <sip:106@10.130.130.58:2051;line=1ofdyu7v>;flow-id=1
Event: dialog
Accept: application/dialog-info+xml
Expires: 0
Content-Length: 0

From the sample above we can see that:

1. SUBSCRIBE sip:136@10.130.130.4;user=phone SIP/2.0 – In this line we can see that the SIP message
is a SUBSCRIBE message and that the extension being monitored is 136 registered to IP PBX
10.130.130.4
2. From: <sip:106@10.130.130.4>;tag=4fog9tlb9d – The subscriber, in this example extension 106
registered to IP PBX 10.130.130.4.
3. Expires: 0 – This specifies the IP PBX that the subscriber is unsubscribing from the resource.

Once the SUBSCRIBE SIP message is received and successfully processed from the IP PBX, a 200 SIP
message is sent back to the subscriber, as shown in the sample below.

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.130.130.58:2051;branch=z9hG4bK-dg2jd5f8nd0p;rport=2051

Contact: <sip:136@10.130.130.4;user=phone>
To: <sip:136@10.130.130.4;user=phone>;tag=9e6f1e0e

From: <sip:106@10.130.130.4>;tag=4fog9tlb9d

Call-ID: 3c491603553e-z27emqqov573

CSeq: 4 SUBSCRIBE

Expires: 0

Content-Length: 0

Common error codes of subscription events.

• 403 – Forbidden. Server did not authorize the request.
• 423 – Interval to small. The Expires value specified in the SIP message is too short.
• 481 – Subscription does not exist.
• 489 – Bad event. The event package designated is not supported.