Download (direct link):
202 Accepted responsethis indicates that the subscription request has been preliminarily accepted, but is still pending a final decision, which will be indicated in the NOTIFY request.
"489 Bad Event responsethis response is returned when the notifier does not understand an event as described in the Event header.
SUBSCRIBE requests are dialog-establishing requests. A dialog is created when a 2xx response or a NOTIFY request arrives for the SUBSCRIBE request. Subsequent SUBSCRIBE and NOTIFY requests are sent within the created dialog.
The request-URI in an initial SUBSCRIBE request addresses the resource that the subscriber wishes to receive state information about. The Event header identifies the event related to the subscription.
Much like registration, subscriptions are in soft state and need refreshing. The duration of a subscription is indicated in an Expires header. The default value is 1 hour if the header is not present in the SUBSCRIBE request. A subscription is terminated when not refreshed and can be explicitly terminated by sending a SUBSCRIBE request within the dialog and setting the Expires header value to 0.
The event notification framework also introduces the concept of an event package: an extension to the framework. Each event package created introduces a new use case for the event notification framework.
The NOTIFY request payload (body) is used to carry the state information. Each event package defines its own MIME type for carrying such information.
The event template package is a special event package and is associated with other event packages, including itself. Template packages define states that can be applied to other event packages. A subscription to a template package is indicated in
the Event header by appending a period (full stop) to an event package, followed by the template package name: for example, Event: presence.winfo.
8.13.2 State publication (the PUBLISH method)
The event notification framework specifies how to subscribe to the state of an event and how to get notification of changes to the state of an event. It does not specify how the state can be published. However, the SIP extension for state publication specification [Draft-ietf-sip-publish] allows a client to publish its event state to the state agent, which acts as the compiler of such state and generating notifications. This is achieved using the PUBLISH method.
PUBLISH requests are in soft state and need to be refreshed. The Event header defined in [RFC3265] (and in Section 8.13.1) is used by the publisher to identify the event whose state it is publishing. The request-URI is used to identify the resource whose state is being published. An entity tag is used by the client and is supplied by the server to enable the client to update a state using the PUBLISH method. The state of a resource is carried in the body of the PUBLISH request.
8.13.3 SIP for instant messaging
For a more detailed description of instant messaging, please refer to Chapter 24.
SIP is extended for instant messaging by the introduction of the MESSAGE method in [RFC3428].
There are two modes of instant message exchange: page mode and session mode. The MESSAGE method is used in page mode. Page mode is a one-shot instant message where a subsequent instant message is not related, at the protocol level, to the preceding one. It is used when a conversation or interaction is not unexpected.
The request-URI in a MESSAGE request carries the resource where the request will be sent. The MESSAGE request body carries the actual contents of an instant message, which, again, is a MIME type. The most common MIME body uses the text/plain MIME type. For interoperability with non-SIP instant-messaging clients using an IETF standard, the MIME type message/cpim as defined in [Draft-ietf-impp-cpim-msgfmt] Common Presence and Instant Messaging Message Format is used.
Session-based instant messaging uses SIP for signalling and the Message Session Relay Protocol (MSRP) for carrying the data (instant messages) after the session has been established (see Section 24.4 for details about how an instant-messaging session can be established using SIP and SDP, as well as how the MSRP operates).
8.13.4 Reliability of provisional responses
In the basic SIP, provisional responses are transmitted unreliably, unlike the 2xx responses for INVITE requests. It was later discovered that reliability in the transmission of provisional responses in some cases was both important and useful: therefore, [RFC3262] was created. In the 3GPP, reliable provisional responses and their acknowledgments are used to exchange additional SDP offer/answer messages.
The reliability of provisional responses extension only applies to INVITE requests.
A UAC generating an INVITE request and wishing to indicate its support for the reliable provisional responses extension includes the Supported header in the INVITE request with the option tag lOOrel. A UAC requiring the UAS to support the reliable provisional responses extension indicates this by placing the option tag lOOrel in a Require header of the INVITE request.