SIP-Specific Event Notification
obsoletes
- rfc-3265 — Session Initiation Protocol (SIP)-Specific Event Notification
updated by
- rfc-7621 — A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework
updates
Extracted elements (30)
Dialog reuse from RFC 3265 is deprecated because it proved exceedingly confusing and error-prone in implementation (RFC 5057 clarifications remained insufficient). The GRUU mechanism (RFC 5627) provides an unambiguous alternative for targeting subscriptions at specific devices.
The SIP event notification mechanism is explicitly NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. It is scoped to SIP-specific use cases where SIP's user mobility features are relevant; use cases like network management or high-frequency GPS updates are explicitly out of scope.
The Subscription-State 'expires' parameter is mandated in active/pending NOTIFY requests (a change from RFC 3265's discretionary inclusion) because without it, forked SUBSCRIBE responses may not reach the subscriber, leaving it without authoritative subscription duration information.
For backwards compatibility with PINT (RFC 2848), notifiers MAY interpret a SUBSCRIBE request with no Event header field as a request for PINT events. Non-PINT notifiers SHOULD return 489 (Bad Event) for any SUBSCRIBE without an Event header field.
A subscriber starts Timer N (64*T1) when sending a SUBSCRIBE request. If Timer N expires before a NOTIFY is received, the subscription is considered failed. After Timer N expiry, NOTIFY requests that would establish new dialog usages SHOULD be rejected with 481.
Event packages that support state deltas MUST include a version number that increases by exactly one for each NOTIFY transaction in a subscription. If a NOTIFY arrives with a version increment greater than one, the subscriber ignores the delta body and re-subscribes to obtain full state.
If a NOTIFY transaction fails due to receipt of a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the notifier MUST remove the corresponding subscription. If a SUBSCRIBE refresh receives the same error codes, the subscriber MUST consider the subscription terminated.
If a UAS receives a CANCEL request matching a SUBSCRIBE or NOTIFY transaction, it MUST respond to the CANCEL request but otherwise ignore it; the CANCEL MUST NOT affect processing of the SUBSCRIBE or NOTIFY request in any way.
Notifiers MUST implement the GRUU extension (RFC 5627) and MUST use a GRUU as their local target. Subscribers MUST NOT attempt to reuse dialogs whose remote target is a GRUU.
Notifiers MUST NOT create subscriptions except upon receipt of a SUBSCRIBE request. The only permitted exception for historical reasons is the implicit subscription creation defined in RFC 3515 (REFER).
NOTIFY requests MUST contain a Subscription-State header field. If value is 'active' or 'pending', the notifier MUST include an 'expires' parameter for remaining subscription time; this mechanism MUST NOT be used to lengthen a subscription beyond what was negotiated.
Proxies that did not add a Record-Route header to the initial SUBSCRIBE request MUST NOT add a Record-Route header to any of the associated NOTIFY requests.
SUBSCRIBE requests SHOULD contain an Expires header field; if absent, the default MUST be defined by the event package. 200-class responses to SUBSCRIBE MUST contain an Expires header field that MAY be shorter but MUST NOT be longer than specified in the request.
Subscribers MUST include exactly one Event header field in SUBSCRIBE requests indicating the event package being subscribed to. The corresponding NOTIFY's Event header field MUST match the SUBSCRIBE's Event header field.
To prevent event spoofing, NOTIFY requests SHOULD be authenticated using any defined SIP authentication mechanism, such as those described in RFC 3261 Sections 22.2 and 23.
Upon receiving a NOTIFY request that does not match any outstanding subscription, the subscriber MUST return a 481 (Subscription does not exist) response unless another 400- or 500-class response is more appropriate.
Upon successfully accepting or refreshing a subscription, notifiers MUST immediately send a NOTIFY request communicating current resource state to the subscriber. This applies regardless of whether authorization has been completed.
Notifiers may use a privacy mechanism to mask authorization decisions: instead of revealing a rejection, a notifier sends 200 OK to the SUBSCRIBE and then sends a NOTIFY with neutral or fake state, hiding whether authorization was granted or denied from the subscriber.
Allow-Events header field: if present, MUST list all event packages for which the UA can act as notifier. MUST NOT be inserted by proxies. Should appear in dialog-initiating methods and their responses, and in OPTIONS responses.
Event header field: identifies the event package for a subscription or notification. Both SUBSCRIBE and NOTIFY requests MUST contain exactly one Event header field with a registered token. Event template-packages are applied by appending '.templatename' to the base package name (e.g., 'presence.winfo').
NOTIFY method: sent by notifiers to inform subscribers of resource state changes. It is a target refresh request and does not terminate its corresponding subscription; a single SUBSCRIBE may trigger multiple NOTIFY requests over the subscription lifetime.
SUBSCRIBE method: used to request current state and state updates from a remote node. It is a target refresh request and a dialog-creating method. The Expires header field indicates subscription duration; an Expires of 0 constitutes an unsubscription and also triggers a state fetch.
Subscription-State header field: mandatory in all NOTIFY requests; value is 'active', 'pending', or 'terminated'. For active/pending, MUST include an 'expires' parameter. For terminated, SHOULD include a 'reason' parameter (deactivated, probation, rejected, timeout, giveup, noresource, invariant) and optionally a 'retry-after' parameter.
IANA Event Packages registry: event packages must be registered with IANA. Registration template requires package name, contact, reference, and addresses for each of the mandatory sections (parameters, body formats, subscription duration, forking behavior, rate limits, state aggregation).
IANA Subscription-State Reason Codes registry: created to register reason codes used in the 'reason' parameter of the Subscription-State header field. Initial registrations: deactivated, probation, rejected, timeout, giveup, noresource, invariant.
Man-in-the-middle attacks can intercept or modify SUBSCRIBE/NOTIFY messages. SIP authentication mechanisms (S/MIME or TLS transport) SHOULD be used; proxies cannot rely on being able to access S/MIME-encrypted SUBSCRIBE/NOTIFY content.
Notifiers SHOULD enforce access control for subscriptions via access control lists or real-time user interaction. If authorization fails, the notifier SHOULD reply with 403 (Forbidden) or 603 (Decline) unless doing so would reveal private information about the subscriber's authorization status.
The SUBSCRIBE/NOTIFY mechanism is susceptible to denial-of-service attacks where an attacker creates subscriptions that cause excessive NOTIFY traffic toward a victim. Authentication of SUBSCRIBE requests and rate limiting of notifications per event package are the primary mitigations.
Notifier subscription state machine defines states: init, resp_wait, pending, active, terminated. Transitions are triggered by receiving SUBSCRIBE, policy decisions granting/denying authorization, NOTIFY transaction failures, subscription expiry, or local policy termination.
Subscriber subscription state machine defines states: init, notify_wait, pending, active, terminated. Transitions are triggered by sending SUBSCRIBE, receiving NOTIFY with state values (active/pending/terminated), Timer N expiry, or specific error responses to SUBSCRIBE refresh. Multiple independent state machines may run from a single forked SUBSCRIBE request.