Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 6665 Tekelec
Obsoletes: 3265 July 2012
Updates: 3261, 4660
Category: Standards Track
SIP-Specific Event Notification
This document describes an extension to the Session Initiation
Protocol (SIP) defined by RFC 3261. The purpose of this extension is
to provide an extensible framework by which SIP nodes can request
notification from remote nodes indicating that certain events have
Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.
This document represents a backwards-compatible improvement on the
original mechanism described by RFC 3265, taking into account several
years of implementation experience. Accordingly, this document
obsoletes RFC 3265. This document also updates RFC 4660 slightly to
accommodate some small changes to the mechanism that were discussed
in that document.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
The ability to request asynchronous notification of events proves
useful in many types of SIP services for which cooperation between
end-nodes is required. Examples of such services include automatic
callback services (based on terminal state events), buddy lists
(based on user presence events), message waiting indications (based
on mailbox state change events), and PSTN and Internet
Internetworking (PINT) [RFC2848] status (based on call state events).
The methods described in this document provide a framework by which
notification of these events can be ordered.
The event notification mechanisms defined herein are NOT intended to
be a general-purpose infrastructure for all classes of event
subscription and notification. Meeting requirements for the general
problem set of subscription and notification is far too complex for a
single protocol. Our goal is to provide a SIP-specific framework for
event notification that is not so complex as to be unusable for
simple features, but that is still flexible enough to provide
powerful services. Note, however, that event packages based on this
framework may define arbitrarily elaborate rules that govern the
subscription and notification for the events or classes of events
This document does not describe an extension that may be used
directly; it must be extended by other documents (herein referred to
as "event packages"). In object-oriented design terminology, it may
be thought of as an abstract base class that must be derived into an
instantiable class by further extensions. Guidelines for creating
these extensions are described in Section 5.
1.1. Overview of Operation
The general concept is that entities in the network can subscribe to
resource or call state for various resources or calls in the network,
and those entities (or entities acting on their behalf) can send
notifications when those states change.
A typical flow of messages would be:
|-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information
|<------NOTIFY----- | Return current state information
Subscriptions are expired and must be refreshed by subsequent
1.2. Documentation Conventions
There are several paragraphs throughout this document that provide
motivational or clarifying text. Such passages are non-normative and
are provided only to assist with reader comprehension. These
passages are set off from the remainder of the text by being indented
This is an example of non-normative explanatory text. It does not
form part of the specification and is used only for clarification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In particular, implementors need to take careful note of the meaning
of "SHOULD" defined in RFC 2119. To rephrase: violation of "SHOULD"-
strength requirements requires careful analysis and clearly
enumerable reasons. It is a protocol violation to fail to comply
with "SHOULD"-strength requirements whimsically or for ease of
Event Package: An event package is an additional specification that
defines a set of state information to be reported by a notifier to
a subscriber. Event packages also define further syntax and
semantics that are based on the framework defined by this document
and are required to convey such state information.
Event Template-Package: An event template-package is a special kind
of event package that defines a set of states that may be applied
to all possible event packages, including itself.
Notification: Notification is the act of a notifier sending a NOTIFY
request to a subscriber to inform the subscriber of the state of a
Notifier: A notifier is a user agent that generates NOTIFY requests
for the purpose of notifying subscribers of the state of a
resource. Notifiers typically also accept SUBSCRIBE requests to
Subscriber: A subscriber is a user agent that receives NOTIFY
requests from notifiers; these NOTIFY requests contain information
about the state of a resource in which the subscriber is
interested. Subscribers typically also generate SUBSCRIBE
requests and send them to notifiers to create subscriptions.
Subscription: A subscription is a set of application state
associated with a dialog. This application state includes a
pointer to the associated dialog, the event package name, and
possibly an identification token. Event packages will define
additional subscription state information. By definition,
subscriptions exist in both a subscriber and a notifier.
Subscription Migration: Subscription migration is the act of moving
a subscription from one notifier to another notifier.
3. SIP Methods for Event Notification
The SUBSCRIBE method is used to request current state and state
updates from a remote node. SUBSCRIBE requests are target refresh
requests, as that term is defined in [RFC3261].
3.1.1. Subscription Duration
SUBSCRIBE requests SHOULD contain an "Expires" header field (defined
in [RFC3261]). This expires value indicates the duration of the
subscription. In order to keep subscriptions effective beyond the
duration communicated in the "Expires" header field, subscribers need
to refresh subscriptions on a periodic basis using a new SUBSCRIBE
request on the same dialog as defined in [RFC3261].
If no "Expires" header field is present in a SUBSCRIBE request, the
implied default MUST be defined by the event package being used.
200-class responses to SUBSCRIBE requests also MUST contain an
"Expires" header field. The period of time in the response MAY be
shorter but MUST NOT be longer than specified in the request. The
notifier is explicitly allowed to shorten the duration to zero. The
period of time in the response is the one that defines the duration
of the subscription.
An "expires" parameter on the "Contact" header field has no semantics
for the SUBSCRIBE method and is explicitly not equivalent to an
"Expires" header field in a SUBSCRIBE request or response.
A natural consequence of this scheme is that a SUBSCRIBE request with
an "Expires" of 0 constitutes a request to unsubscribe from the
In addition to being a request to unsubscribe, a SUBSCRIBE request
with "Expires" of 0 also causes a fetch of state; see
Notifiers may also wish to cancel subscriptions to events; this is
useful, for example, when the resource to which a subscription refers
is no longer available. Further details on this mechanism are
discussed in Section 4.2.2.
3.1.2. Identification of Subscribed Events and Event Classes
Identification of events is provided by three pieces of information:
Request URI, Event Type, and (optionally) message body.
The Request URI of a SUBSCRIBE request, most importantly, contains
enough information to route the request to the appropriate entity per
the request routing procedures outlined in [RFC3261]. It also
contains enough information to identify the resource for which event
notification is desired, but not necessarily enough information to
uniquely identify the nature of the event (e.g.,
"sip:email@example.com" would be an appropriate URI to subscribe to
for my presence state; it would also be an appropriate URI to
subscribe to the state of my voice mailbox).
Subscribers MUST include exactly one "Event" header field in
SUBSCRIBE requests, indicating to which event or class of events they
are subscribing. The "Event" header field will contain a token that
indicates the type of state for which a subscription is being
requested. This token will be registered with the IANA and will
correspond to an event package that further describes the semantics
of the event or event class.
If the event package to which the event token corresponds defines
behavior associated with the body of its SUBSCRIBE requests, those
Event packages may also define parameters for the "Event" header
field; if they do so, they must define the semantics for such
3.1.3. Additional SUBSCRIBE Header Field Values
Because SUBSCRIBE requests create a dialog usage as defined in
[RFC3261], they MAY contain an "Accept" header field. This header
field, if present, indicates the body formats allowed in subsequent
NOTIFY requests. Event packages MUST define the behavior for
SUBSCRIBE requests without "Accept" header fields; usually, this will
connote a single, default body type.
Header values not described in this document are to be interpreted as
described in [RFC3261].
NOTIFY requests are sent to inform subscribers of changes in state to
which the subscriber has a subscription. Subscriptions are created
using the SUBSCRIBE method. In legacy implementations, it is
possible that other means of subscription creation have been used.
However, this specification does not allow the creation of
subscriptions except through SUBSCRIBE requests and (for backwards-
compatibility) REFER requests [RFC3515].
NOTIFY is a target refresh request, as that term is defined in
A NOTIFY request does not terminate its corresponding subscription;
in other words, a single SUBSCRIBE request may trigger several NOTIFY
3.2.1. Identification of Reported Events, Event Classes, and Current
Identification of events being reported in a notification is very
similar to that described for subscription to events (see
As in SUBSCRIBE requests, NOTIFY request "Event" header fields MUST
contain a single event package name for which a notification is being
generated. The package name in the "Event" header field MUST match
the "Event" header field in the corresponding SUBSCRIBE request.
Event packages may define semantics associated with the body of their
NOTIFY requests; if they do so, those semantics apply. NOTIFY
request bodies are expected to provide additional details about the
nature of the event that has occurred and the resultant resource
When present, the body of the NOTIFY request MUST be formatted into
one of the body formats specified in the "Accept" header field of the
corresponding SUBSCRIBE request (or the default type according to the
event package description, if no "Accept" header field was
specified). This body will contain either the state of the
subscribed resource or a pointer to such state in the form of a URI
(see Section 5.4.13).