The Internet Engineering Task Force (IETF) met for the 65th time in late March in Dallas. The meeting was historic for many reasons. It was the 20th anniversary of the IETF, and it was also coincident with the largest rainfall Dallas had seen in 20 years. The downpour was so bad that the parking lots were flooded with two feet of water, and new guests could not check in at the hotel. This downpour was also symbolic of the meeting itself.

Talk of SIP was seemingly everywhere. There was a new IETF area dedicated to SIP and SIP-related topics, new area directors were pulled from the SIP community, and a new pre-working group was looking at peer-to-peer SIP. This trend is happening in the industry, as well. SIP is everywhere. We’ve now got a magazine devoted to it (this fine publication), and the IP Multimedia Subsystem (IMS), a SIP-based network for service providers, is the new darling of the telecom industry, attracting even more hype than SIP itself.

This deluge has, unsurprisingly, raised a flurry of interest in using SIP for all kinds of applications. SIP is obviously well-suited for interactive multimedia communications, including voice over IP (VoIP) and video telephony. It’s also been extended to support presence and instant messaging. These days, it’s starting to get mentioned in the context of other applications — interactive TV, gaming, messaging, video on demand, and virtual private networks (VPNs), to name a few.

One of the drivers behind this is IMS, and the argument goes something like this: Service providers are spending a bundle of cash in the development and eventual large-scale deployment of IMS. Its purpose is to serve as a control layer for SIP-based applications in the network. Once they’ve spent the money, it would be nice to use that infrastructure for other types of applications too. Indeed, most of the applications on that list do have the notion of a session — there is a start and a stop, and usually the delivery of some kind of media throughout that session. Since SIP is all about managing sessions, couldn’t it be used there too? Indeed, it’s not an unreasonable argument.

Native Versus Encapsulated Use

SIP can be used to support those other applications in two ways. One is natively, where SIP is extended with the new functions necessary to support those applications. The other is encapsulated, where SIP is merely used as a wrapper to signal the beginning and end of a session, while some other protocol is used for the actual application-specific communications. Native solutions are frequently problematic, since they can require substantial changes to SIP and may be unachievable given SIP’s design. As an example, one might try to use SIP for Web browsing. Rather than send an HTTP GET command for content, SIP would send an INVITE command to establish a content-transfer session. SIP would work poorly in this model. SIP INVITE requests cannot be pipelined the way HTTP requests can be, and that leads to poor Web performance. SIP also lacks any capabilities for caching, a key piece of HTTP functionality.

The more interesting approach is to encapsulate another protocol in SIP. In the example of Web browsing, HTTP would still be used. A SIP INVITE command would establish an HTTP session; it would be followed by HTTP requests for the content; and the session would conclude with a SIP BYE command. A similar model has been proposed for streaming media, traditionally done with Real Time Streaming Protocol (RTSP). An INVITE command would be used to start the streaming media session, followed by RTSP requests to perform the “trick plays” (fast-forward, rewind, pause, etc.), and ending with a SIP BYE.

The encapsulated mode certainly works. The question is, does it bring any real benefits? It has clear drawbacks: It increases the volume of messaging over access links and within the network, since it is adding to what was used previously. It can also increase the amount of time it takes to establish the session, and it increases the overall processing load in the network.

Benefits Not Assured

The benefits depend on whether the processing performed by SIP servers in the network, such as the Call Session Control Function (CSCF), can now be usefully reused. There are two in particular worth considering: allocation of network quality of service (QoS) and service authorization. In the IMS, the CSCFs enable QoS by communicating with a policy server. That functionality can be reused only if the Session Description Protocol (SDP) body is present in a SIP message. SDP was designed to describe multimedia communications sessions using codecs; it cannot readily describe more complex sessions like real-time gaming, which have different traffic properties from those of interactive media, and are not really represented by a codec at all.

Another functionality provided by the CSCF is service authorization; applications are invoked if the subscriber profile indicates that the application is permitted for that subscriber. This is effectively a flag of sorts, indicating whether an application is enabled or disabled for a subscriber. These mechanisms work well for typical interactive communications applications. However, other services may have other needs. For example, authorization for streaming media services is likely to require the use of digital rights management (DRM) technologies to authorize access to content. This kind of functionality is not provided at all by IMS. Thus, the CSCF authorization functions would not help here.

In essence, one must always choose the right protocol for the right job. Different applications have differing requirements, and these demand different protocols. SIP is not well-suited to be the common layer for all IP-based applications. To quote my wise colleague Dave Oran, “There is a reason IP is at the waist of the hourglass, not SIP.” The “hourglass” refers to the IP design philosophy, where IP is at the middle, numerous link-layer technologies are under it, and many applications are on top of it, all unified by IP. This hourglass model for IP has proven itself to be right time and time again, with IP serving as the common basis for new applications each year.

As the Internet continues its growth, touching more people and moving faster and faster, the deluge of IPbased applications will continue. Although SIP-based applications will be a part of these, they will only be a part, not the whole.

Jonathan Rosenberg is co-author of the original SIP specification (RFC 3261). He is currently a Cisco Fellow and Director of VoIP Service Provider Architecture for the Broadband Subscriber Applications Business Unit in the Voice Technology Group at Cisco Systems. (news - alert)