Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

The ims ip multimedia concepts and services and services in the mobile domain - Mayer G.

Mayer G. The ims ip multimedia concepts and services and services in the mobile domain - Wiley publishing , 2004 . - 450 p.
Download (direct link): thsipmultiaсon2004.pdf
Previous << 1 .. 101 102 103 104 105 106 < 107 > 108 109 110 111 112 113 .. 149 >> Next

• “202 Accepted” response—this 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” response—this 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
SIP
289
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).
290
The IMS
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.
Previous << 1 .. 101 102 103 104 105 106 < 107 > 108 109 110 111 112 113 .. 149 >> Next