Understanding the SIP NOTIFY Method and Event Notification Framework

Overview

Key takeaways

• SIP NOTIFY communicates asynchronous state updates from an Event Server (Notifier) to a Subscriber.
• Every NOTIFY request must include an Event header and a Subscription-State header (active, pending, or terminated).
• NOTIFY is paired primarily with SUBSCRIBE requests, but is also triggered implicitly by REFER requests during call transfers.
• Unsolicited NOTIFY messages exist in legacy or specialized deployments (e.g., event-less MWI or device sync), though RFC 6665 mandates an active subscription context.

Prerequisites

• Understanding of core SIP architecture, transactions, and dialogs (RFC 3261).
• Familiarity with standard SIP headers such as To, From, Call-ID, CSeq, and Content-Type.
• Basic knowledge of SIP presence, voicemail (MWI), or call transfer flows.

Guide

1. section #1

   The Role of SIP NOTIFY in Event Notifications The SIP NOTIFY method enables endpoints and servers to push real-time event updates without requiring continuous polling. Defined as part of the SIP Specific Event Notification framework in RFC 3265 (and later revised in RFC 6665), NOTIFY allows a notifier to inform a subscriber whenever a resource state changes. Common event types include Message Waiting Indicators (MWI), dialog state for Busy Lamp Field (BLF) features, presence state, and call progress tracking during blind or attended call transfers triggered by a REFER request.

2. section #2

   Anatomy of a SIP NOTIFY Request A standard SIP NOTIFY request must include key headers that correlate the notification to its corresponding subscription state and event package. The 'Event' header identifies the specific package (e.g., 'message-summary', 'dialog', 'presence'). The 'Subscription-State' header conveys the current lifecycle of the subscription ('active', 'pending', or 'terminated'). If the state is 'terminated', an optional 'reason' parameter explains why the subscription ended, such as 'timeout' or 'deactivated'. Additionally, the body of the NOTIFY carries the MIME payload containing the actual state data.

   textcopy

   NOTIFY sip:alice@192.168.1.50:5060 SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-3342-1
   From: <sip:100@192.168.1.1>;tag=as5d1a2b
   To: "Alice" <sip:alice@192.168.1.50>;tag=9a8c7b6a
   Call-ID: 7a8b9c0d1e2f3a4b@192.168.1.50
   CSeq: 102 NOTIFY
   Contact: <sip:100@192.168.1.1:5060>
   Event: message-summary
   Subscription-State: active;expires=3600
   Max-Forwards: 70
   Content-Type: application/simple-message-summary
   Content-Length: 91
   
   Messages-Waiting: yes
   Message-Account: sip:alice@example.com
   Voice-Message: 2/5 (0/1)

3. section #3

   Subscription Lifecycle and NOTIFY Rules RFC 6665 dictates strict rules regarding the subscription lifecycle. Upon receiving a SUBSCRIBE request, the notifier sends a 200 OK response and must immediately follow with an initial NOTIFY request to transmit the current state of the resource. This initial NOTIFY confirms the establishment of the event dialog. Subsequent NOTIFY requests are sent whenever the state changes. When the subscription expires or is explicitly canceled by setting the 'Expires: 0' header in a SUBSCRIBE, the notifier issues a final NOTIFY with a 'Subscription-State: terminated' header, formally closing the event dialog.

   textcopy

   Subscriber                  Notifier
       |                           |
       |------ SUBSCRIBE --------->|
       |<------- 200 OK -----------|
       |<------- NOTIFY -----------|  (Initial state: Subscription-State: active)
       |------- 200 OK ----------->|
       |                           |
       |   [Resource State Changes]|
       |<------- NOTIFY -----------|  (Updated state)
       |------- 200 OK ----------->|
       |                           |
       |<------- NOTIFY -----------|  (Final state: Subscription-State: terminated)
       |------- 200 OK ----------->|

4. section #4

   Common Event Packages using NOTIFY SIP NOTIFY is utilized across several key VoIP applications. Message Waiting Indication (RFC 3842) uses the 'message-summary' event package to notify phones of unread voicemail messages. Busy Lamp Field (BLF, RFC 4235) uses the 'dialog' event package to monitor extension status (idle, ringing, or on a call). Presence (RFC 3856) uses PIDF/XML payloads under the 'presence' event package to communicate user availability. Finally, explicit call transfers using the REFER method (RFC 3515) automatically create an implicit subscription where NOTIFY messages convey the progress (e.g., 100 Trying, 200 OK) of the transferred call leg.

5. section #5

   Handling Unsolicited NOTIFY Messages While RFC 6665 specifies that NOTIFY messages must only occur within a valid subscription established by SUBSCRIBE or REFER, some proprietary or legacy VoIP systems send 'unsolicited NOTIFY' requests. For example, some IP PBXs push firmware update commands, phone reboot triggers (using vendor-specific events like 'check-sync'), or MWI updates directly to devices without an prior SUBSCRIBE transaction. Modern SIP proxies and User Agents must be configured to handle or intentionally filter unsolicited NOTIFY requests to avoid security vulnerabilities or unexpected behavior.

6. section #6

   Troubleshooting and Security Best Practices When troubleshooting SIP NOTIFY transactions using tools like Wireshark, ensure that every NOTIFY is matched by a 200 OK response from the subscriber. If a subscriber returns a 481 'Call/Transaction Does Not Exist' error, it indicates that the subscriber has no record of the subscription dialog, often caused by a restart or expired timers. Security best practices mandate authenticating SUBSCRIBE requests to prevent unauthorized eavesdropping on call states, rate-limiting NOTIFY transmissions to mitigate denial-of-service attacks, and enforcing TLS/SRTP to protect sensitive state information contained within notification payloads.

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 3515 - The Session Initiation Protocol (SIP) Refer Method