SIP Event Notification Framework (RFC 6665): Architecture of SUBSCRIBE

Overview

Key takeaways

• RFC 6665 updates and clarifies RFC 3265, fixing edge cases in dialog creation, fork handling, and subscription state machines.
• A SUBSCRIBE request establishes a temporal subscription to a specific state resource using an Event header field.
• The Notifier MUST immediately send a NOTIFY request upon receiving and accepting a valid SUBSCRIBE request to communicate current state.
• Subscription lifetimes are controlled via the Expires header and must be explicitly refreshed before timing out.
• The Subscription-State header in NOTIFY requests manages state transitions (active, pending, terminated) and retry intervals.

Prerequisites

• Understanding of basic SIP core concepts (RFC 3211 / RFC 3261) including transactions, dialogs, and headers.
• Familiarity with SIP Request/Response sequences and URI formatting.

Guide

1. section #1

   Introduction to RFC 6665 and Event-Driven SIP While standard SIP (RFC 3261) primarily handles session establishment and teardown, many telecommunication services require asynchronous notification of state changes without maintaining an active media session. RFC 6665 defines a generic framework for SIP endpoints to request and receive event notifications. Obsoleting RFC 3265, RFC 6665 refines the subscription state machine, fixes issues with dialog reuse and parallel forking, and provides a robust mechanism for applications such as Message Waiting Indicators (MWI), presence awareness, line status monitoring (BLF), and call state tracking.

2. section #2

   Roles, Terminology, and Event Packages The framework operates around two primary roles: the Subscriber (a User Agent Client that requests state updates) and the Notifier (a User Agent Server that generates state updates). Because generic SIP does not know how to interpret specific application state changes, the framework relies on Event Packages. An Event Package is a concrete specification (such as RFC 3842 for MWI or RFC 4235 for Dialog State) that defines the Event header token, the content types allowed in NOTIFY bodies, and the rules for state aggregation and authorization.

3. section #3

   Subscription Establishment and Dialog Management A subscription is initiated when a Subscriber sends a SUBSCRIBE request targeting a specific resource URI and including an Event header. Subscriptions exist within a SIP dialog. If the SUBSCRIBE is sent outside an existing dialog, a successful response (typically 200 OK or 202 Accepted) along with the corresponding NOTIFY creates a new dialog. RFC 6665 strictly mandates that a subscription dialog is identified by the standard SIP dialog ID tuple (Call-ID, From tag, To tag). Re-SUBSCRIBE requests are sent within the established dialog to extend the expiration timer or alter parameters.

4. section #4

   The Immediate NOTIFY Requirement and Subscription States A critical architectural constraint in RFC 6665 is the mandatory immediate NOTIFY. When a Notifier accepts a SUBSCRIBE request (returning a 200-class response), it MUST immediately issue a NOTIFY request within the same subscription context. This guarantees state synchronization even if no event state has changed. Every NOTIFY request carries a 'Subscription-State' header field indicating the status of the subscription: 'active' (accepted and monitored), 'pending' (accepted but awaiting authorization or resource readiness), or 'terminated' (ended, with an optional reason parameter such as 'deactivated', 'probation', or 'timeout').

5. section #5

   Lifecycle, Refresh, and Termination Mechanics Subscriptions are time-bound resources. The requested duration is conveyed in the 'Expires' header of the SUBSCRIBE request. The Notifier may shorten this duration in its 200 OK response, but cannot lengthen it. The Subscriber is responsible for sending a refresh SUBSCRIBE before the timer expires—typically at half the negotiated expiration interval. To explicitly terminate a subscription before its natural expiration, the Subscriber sends an in-dialog SUBSCRIBE with 'Expires: 0'. The Notifier responds with 200 OK and sends a final NOTIFY with 'Subscription-State: terminated'.

6. section #6

   Protocol Message Flow and Structural Example The following example demonstrates the SIP transaction flow for establishing a line state subscription (dialog event package) between a Subscriber phone and a SIP PBX Notifier, including the immediate initial state NOTIFY.

   sipcopy

   SUBSCRIBE sip:101@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-73a12
   From: <sip:100@example.com>;tag=sub-tag-01
   To: <sip:101@example.com>
   Call-ID: c309118a-9281a@192.168.1.50
   CSeq: 1 SUBSCRIBE
   Event: dialog
   Expires: 3600
   Accept: application/dialog-info+xml
   Contact: <sip:100@192.168.1.50:5060>
   
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-73a12;received=192.168.1.50
   From: <sip:100@example.com>;tag=sub-tag-01
   To: <sip:101@example.com>;tag=not-tag-99
   Call-ID: c309118a-9281a@192.168.1.50
   CSeq: 1 SUBSCRIBE
   Expires: 3600
   Contact: <sip:101@10.0.0.1:5060>
   
   NOTIFY sip:100@192.168.1.50:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK-8812c
   From: <sip:101@example.com>;tag=not-tag-99
   To: <sip:100@example.com>;tag=sub-tag-01
   Call-ID: c309118a-9281a@192.168.1.50
   CSeq: 101 NOTIFY
   Event: dialog
   Subscription-State: active;expires=3600
   Content-Type: application/dialog-info+xml
   Content-Length: 188
   
   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:101@example.com">
     <dialog id="d1">
       <state>terminated</state>
     </dialog>
   </dialog-info>

Further reading

• RFC 6665 - SIP-Specific Event Notification
• RFC 3842 - A Message Summary and Message Waiting Indication Event Package for SIP
• RFC 4235 - An INVITE-Initiated Dialog Event Package for SIP
• RFC 3863 - Presence Information Data Format (PIDF)