SIP Everywhere but NOT for Everything

Have you already heard or read, as I have, that a problem with IMS was that the SIP protocol cannot support all services?

Such a statement reveals a big misunderstanding about the nature of SIP.

One of the greatest strengths of this protocol is that it does not try to do everything, but instead to reuse and integrate with other more specialized protocols.

Here follow some examples.

The SIP session

I already described it but it is important to insist. The concept of SIP session is very generic and is not tied to any medium or content.

In practice, SIP can be used by a peer (user or application) to:
- Locate and contact another peer (user or application) whose association to a device or network access point can be dynamic (the association is performed through registration) and multiple (the peer can use different devices or access points at the same time).
- Agree on the principle of a communication with the peer.
- Negotiate the content(s) of the session.
- Possibly re-negotiate the content(s) of the session later on.
- Finally terminate the session.

Any relevant service protocol can be used within the session, be it RTP (e.g. voice, video), RTSP (streaming), MSRP (messaging), or any application to application standard or proprietary protocol.

First example: SIP for session control, any other service-specific protocol(s) within the session.

SIP Content Indirection

SIP content indirection allows a SIP message to indicate to the recipient that it should retrieve a content identified by a URI included in the SIP message. The URI scheme determines the protocol to use (e.g. HTTP, XCAP, FTP, RTSP) and specific SIP headers provide additional information about the content such as what to do with it (e.g. store, display, execute), its size, or its expiracy time.

A typical usage of content indirection permits a service to a redirect a client to a web page offering an advanced user interface for the user to interact with the service.

Another one is associated to SIP NOTIFY. NOTIFY is used to report an event state or a change to an event state to the client. This event state can actually consist of an XML document which is too voluminous to be included in the body of the NOTIFY (e.g. rich presence information, user profile data). The NOTIFY will therefore use content indirection and ask the client to retrieve the document via a more appropriate protcol, e.g. HTTP or XCAP.

A third one would make use of content indirection for a user to provide access to a file (e.g. picture, video clip, love letter) stored in a network repository to other users, through sending a text IM (SIP MESSAGE) with content indirection. Compared to a more intrusive push approach, content indirection permits the recipients to decide whether or not they want to retrieve the content, as well as when they feel appropriate to do it.

Second example: SIP message includes URI to access content using another protocol

SIP REFER

SIP REFER permits peer A to request peer B to initiate a service interaction towards peer C or a server. Peer B may decide to initiate the service interaction or not, and this service interaction may succeed or fail. REFER is implicitly associated to an event package, which makes that peer B will notify peer A about the processing of the request (SIP NOTIFY).

While REFER was initially introduced to support SIP session transfer and ad-hoc conferencing, which implies that the request is to use SIP towards another peer, the specification does not place any constraint on the URI peer B is referred to. It can therefore be of any scheme, such as SMTP (email), HTTP, or RTSP (streaming).

REFER is therefore another way for a SIP peer to ask another SIP peer to use another protocol to access a service.

Third example: SIP REFER permits to explicitly ask the SIP recipient to use another protocol to access a service.

SIP as a service semantic transport protocol

A SIP message has a body, and this body can include any type of content, such as documents defining service control semantic.

The first example of this usage came with SIP session initiation, with a SIP INVITE transporting an SDP (Session Description Protocol) document to negotiate the content and conditions of the session.

However, SIP is not limited to transporting SDP documents, and SIP methods like PUBLISH, SUBSCRIBE, NOTIFY, and MESSAGE can typically transport XML documents.

The only limitation is that SIP is not supposed to be a transport protocol, and the size of the attached document should remain small. However, if it reaches a size threshold, content indirection can be used to provide alternative access to the service semantic.

Fourth example: SIP used as a service control transport/indirection protocol.

SIP as a federator for other service protocols

I personally envision a potential future in which SIP would be used in the process of delivering multiple services, but rarely as the main service protocol. Rather as a mediator between the user and the service, as the glue between multiple service protocols, or as the integrator of service delivery into a coherent context, the SIP session.

I will have opportunities to refine these ideas.

“SIP just amazes me - I’ll bet you five years from now even your fridge will be controlled by SIP”
Earl Turner, Time Warner Telecom’s senior director of VoIP technology, Supercomm 2005

Christophe