Understanding SIP Presence and Busy Lamp Field (BLF) Architecture

Overview

Key takeaways

• BLF typically utilizes the 'dialog' event package (RFC 4235) to monitor line states (idle, ringing, busy).
• Rich Presence uses the 'presence' event package and PIDF/Presence Information Data Format (RFC 3856 / RFC 3863) to share user-centric availability.
• The SIP Event Framework relies on an implicit subscription state machine driven by SUBSCRIBE and NOTIFY transactions.
• SIP PUBLISH (RFC 3903) allows User Agents to push state updates to a centralized Presence Agent without requiring active inbound subscriptions.
• Handling high-volume BLF subscriptions requires optimizing Presence Agent memory, state caching, and NOTIFY rate-limiting.

Prerequisites

• Basic understanding of SIP transactions, dialogs, and headers (RFC 3261)
• Familiarity with XML syntax used in SIP event payloads
• General knowledge of PBX line keys and attendant console functionality

Guide

1. section #1

   The SIP Event Notification Framework (RFC 6665) SIP Presence and Busy Lamp Field (BLF) are built on top of the SIP Specific Event Notification framework, originally defined in RFC 3265 and updated in RFC 6665. Unlike standard call setup dialogs initiated by INVITE, event notifications establish a long-lived subscription dialog using the SUBSCRIBE method. The Subscriber (typically an IP phone or softphone) sends a SUBSCRIBE request to a Notifier (a SIP PBX or Presence Agent) specifying an 'Event' header. The Notifier accepts the subscription with a 200 OK and immediately sends an initial NOTIFY request containing the current state of the monitored resource. Subsequent NOTIFY requests are pushed automatically whenever the state changes.

   sipcopy

   SUBSCRIBE sip:101@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-7331-1
   From: "Receptionist" <sip:100@example.com>;tag=sub1234
   To: <sip:101@example.com>
   Call-ID: sub-dialog-8932@192.168.1.50
   CSeq: 1 SUBSCRIBE
   Event: dialog
   Expires: 3600
   Accept: application/dialog-info+xml
   Contact: <sip:100@192.168.1.50:5060>
   Content-Length: 0

2. section #2

   Busy Lamp Field (BLF) and the Dialog Event Package Busy Lamp Field (BLF) is a feature used on IP desk phones and attendant consoles to display the real-time telephony state of specified extension keys (e.g., green for idle, blinking red for ringing, solid red for in-a-call). Underneath the hood, BLF uses the 'dialog' event package defined in RFC 4235. When an monitored extension initiates, receives, or terminates a call, the PBX generates an XML payload formatted as 'application/dialog-info+xml'. This document encapsulates state attributes such as 'trying', 'early' (ringing), 'confirmed' (active call), or 'terminated', enabling the subscriber phone to adjust its physical LED indicators.

   xmlcopy

   NOTIFY sip:100@192.168.1.50:5060 SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-notify-1
   From: <sip:101@example.com>;tag=server123
   To: "Receptionist" <sip:100@example.com>;tag=sub1234
   Call-ID: sub-dialog-8932@192.168.1.50
   CSeq: 101 NOTIFY
   Event: dialog
   Subscription-State: active;expires=3590
   Content-Type: application/dialog-info+xml
   Content-Length: 228
   
   <?xml version="1.0" encoding="UTF-8"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:101@example.com">
     <dialog id="call-9921">
       <state>early</state>
     </dialog>
   </dialog-info>

3. section #3

   Rich Presence and PIDF (RFC 3856 / RFC 3863) While BLF focuses specifically on PBX line state (hook state and call leg details), Rich Presence conveys broader user availability such as 'Away', 'Do Not Disturb', 'In a Meeting', or custom status notes. Presence monitoring uses the 'presence' event package (RFC 3856) and encodes status using the Presence Information Data Format (PIDF, RFC 3863) or extended variations like RPID (RFC 4480). PIDF documents use XML elements like <tuple> and <basic> status (open or closed) along with optional location and activity elements to represent rich user context across Unified Communications (UC) platforms.

   xmlcopy

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:user101@example.com">
     <tuple id="presence-tuple-1">
       <status>
         <basic>open</basic>
       </status>
       <note>In a meeting until 3 PM</note>
     </tuple>
   </presence>

4. section #4

   State Publication with SIP PUBLISH (RFC 3903) In large enterprise environments, endpoints often need to broadcast their presence state to a centralized Presence Agent (PA) without requiring every watching phone to establish a direct subscription to the endpoint. The SIP PUBLISH method (RFC 3903) allows a Presentity (User Agent) to push its current presence or device status to the PA. The PA receives PUBLISH requests, maintains state in memory or a database, and subsequently dispatches NOTIFY messages to all active subscribers. PUBLISH transactions use entity tags (SIP-ETag and SIP-If-Match headers) to manage state overwrites and prevent race conditions.

   sipcopy

   PUBLISH sip:user101@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK-pub-1
   From: <sip:user101@example.com>;tag=pubtag99
   To: <sip:user101@example.com>
   Call-ID: pub-98123-callid@192.168.1.101
   CSeq: 1 PUBLISH
   Event: presence
   Expires: 3600
   Content-Type: application/pidf+xml
   Content-Length: 210
   
   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:user101@example.com">
     <tuple id="t1">
       <status><basic>closed</basic></status>
     </tuple>
   </presence>

5. section #5

   Subscription Lifecycle Management SIP event subscriptions are soft-state transactions bound by expiration timers defined in the 'Expires' header of the SUBSCRIBE request. Subscribers must periodically refresh subscriptions prior to expiration by issuing a re-SUBSCRIBE with the same Call-ID, From tag, and To tag. The Notifier manages the subscription state machine via the 'Subscription-State' header present in all NOTIFY requests. Values include 'active' ( subscription valid), 'pending' (awaiting authorization), or 'terminated' (subscription ended). If 'terminated' is specified, a 'reason' parameter (e.g., 'expired', 'deactivated', 'timeout') informs the subscriber why the monitor was dropped.

6. section #6

   Scalability and Performance Considerations Deploying BLF and Presence in large environments (e.g., 5,000+ IP phones each monitoring 20 BLF keys) creates exponential traffic patterns known as 'NOTIFY storms'. When a single high-profile extension changes state, the Presence Server must generate and transmit thousands of NOTIFY messages concurrently. To mitigate load, VoIP engineers employ key strategies: aggregating notifications, leveraging memory-cached Presence Agents (such as Kamailio presence modules), tuning subscription refresh timers (e.g., setting minimum subscription durations to 1800-3600 seconds), and implementing throttle mechanisms to limit NOTIFY rate-of-burst during burst state transitions.

Further reading

• RFC 6665 - SIP-Specific Event Notification
• RFC 4235 - An INVITE-Initiated Dialog Event Package for SIP
• RFC 3856 - A Presence Event Package for the Session Initiation Protocol (SIP)
• RFC 3903 - Session Initiation Protocol (SIP) Extension for Event Publication
• RFC 3863 - Presence Information Data Format (PIDF)