The last straw for SIP

Is SIP all it's cracked up to be? John Waclawsky, Motorola Inc.'s chief software architect, thinks we ask too much of the protocol - and we're quickly becoming disappointed with its performance. In this article excerpt, courtesy of Business Communications Review magazine, Waclawsky explains why SIP might sink.A decade of development effort has produced hundreds of engineering specifications but has failed to make the IETF's Session Initiation Protocol (SIP) the signaling protocol of choice for popular voice and multimedia applications. Instead, most long distance voice sessions rely on old signaling standbys like SS7 or H.323, while the latest applications like instant messaging, peer-to-peer (P2P) file sharing and VoIP telephony are being built on newer signaling protocols, including IAX, Skype, XMPP and others.SIP began auspiciously enough, by providing total endpoint control of the session initiation process, but the once-simple protocol has become complicated and overextended along the way. Since the 3GPP became interested in SIP, it has evolved towards providing more call control in the network core, via extensions to SIP and the use of techniques such as B2BUAs (back-to-back user agents) and private headers.Now Internet advocates, who still want control at the edge, are frustrated by what they see: SIP becoming a tool for the core network to control user activities. Many engineers have moved on to other protocols. Meanwhile, SIP's more recent proponents, who in fact want extensive call control in the core, are frustrated as well, but by the controls and complexity that SIP still leaves in edge devices. No one seems to be happy.I believe that success for a protocol is proven by widespread usage, not by standards activities, marketing endorsements or even the number of lines of shipping code. Notwithstanding practically every major vendor's marketing claims that they "support SIP," nor the recent co-opting of SIP by the ITU into the IP Multimedia Subsystem (IMS), the facts speak for themselves: SIP is not in widespread use today, and it has been avoided by virtually every successful new Internet-based application. Now even the ITU is having second thoughts about SIP, having initiated exploratory work on an alternative to SIP called H.325.There are two basic questions here, which we will explore further. The first is how SIP could have gone so wrong, and the second is whether the concept of a universal signaling protocol is even appropriate anymore - if it ever was. But first, let's clear up any doubts about SIP's inability to achieve the kind of popularity some of its proponents still want to insist it has.Severe Initiation ProblemsYou could argue that Asterisk and Skype developers had the same business reasons anyone else would have to avoid SIP and create their own proprietary protocols: they want to develop an installed base and leverage that against their competitors. But Asterisk's IAX is open, and both Asterisk and Skype are on the record as having gone their own way because SIP didn't technically satisfy their design needs. More recently, Google chose XMPP, not SIP, as the basis of Google Talk, and Skype is now expanding by targeting business environments with its own (proprietary) session initiation protocol (see the article at www.networkworld.com/news/2006/110706-skype-sets-eyes-on-enterprise.html).Nor has SIP lived up to expectations of mix-and-match interoperability in the enterprise. Sure, every major IP-telephony vendor has implemented "basic" SIP, but they also have implemented many of the hundreds of SIP extensions. Since these additional bits of function are rarely handled the same way, it's nearly impossible for enterprise customers to truly mix and match SIP-compliant components.If you look closely, the major carriers have not really embraced SIP. Many still regard the ISDN-based legacy protocol H.323 as the real VoIP and video-conferencing workhorse. H.323 is also the foundation for cheap calls made using discount cards, and it integrates easily into the carrier billing systems.Last year (2006), the ITU began talking about replacing SIP. The H.325 work was started by ITU-T Study Group 16, which is the lead study group on multimedia systems and audio/video coding. The intent is to explore alternatives to SIP's complexity, inadequate error handling and diagnostics as well as poor negotiation capabilities. An additional goal is to better meet the requirements (modular, faster call establishment, better service control) for the carriers' anticipated next-generation network environments.In May 2006, several presentations at the Joint ITU-T Workshop and IMTC Forum entitled "H.323, SIP: Is H.325 next?" (www.itu.int/ITU-T/worksem/h325/200605/) indicated that SIP is a mistake-ridden practice attempt, and H.325 expects to get it right the next time round. If H.325 proceeds the protocol work is expected to start this year or next.Meanwhile, Figure 1 (page 16) and Table 1 (page 14) illustrate the difference between supporting SIP and using SIP. Figure 1 shows the growing number of SIP-related RFC pages (the IETF's name for a specification) that have been produced through November 2006. The vendors who send their engineers and product managers to the IETF all "support" SIP in this way, by participating in the ongoing (some would say never-ending) standards-setting process.But when it comes to actually using SIP, Table 1 tells the tale. Admittedly, it's mostly about SIMPLE, the SIP for Instant Messaging and Presence protocol, but it makes the point. Moreover, it will have to do, since there are no comparisons of actual usage data for SIP, IAX, MGCP, H.323, et cetera. In Table 1, we see how SIMPLE's competitors have dominated instant messaging in the marketplace.Like IPv6, SIP stacks are embedded in a lot of software, but SIP simply hasn't achieved widespread usage. Why is that?SIP Is ComplicatedIn reality, no single signaling protocol has ever been crowned the universal way to do everything. Instead, several popular protocols have been developed over the years to solve specific problems. For example, SS7 is used for the PSTN user and core network signaling in 99% of PSTN networks, while ISDN has its own user-network signaling. H.323 is used mainly for video conferencing and for VoIP carriage on core networks, while MGCP mainly offloads calls onto IP networks.From a consumer standpoint, SS7 has been a terrific success. Years of public telephony services have made SS7 the gold standard for basic telephony: on-hook, off-hook, ring, busy, et cetera. It's all very basic stuff and it just works. Today, a consumer has no problem going to a store, buying a basic home phone and plugging it in and achieving instant interoperability.SIP is completely different from SS7, but in the last several years, it has come to be accepted that one of SIP's roles will be to replace SS7. SIP's developers have been trying very hard to achieve that and more, by making SIP the Swiss Army knife of IP signaling protocols. Although SIP started out simply, it has been extended again and again. These extensions bring more potential value to developers and to customers - but they also bring more code, more choices, and more state to manage in more network devices - in short, more complexity.For example, more than 80 IETF documents (and climbing) now describe SIP and its extensions: 20 of them cover the core of SIP signaling, but there are at least seven that define extensions for PSTN issues, seven more for security, several more for conferencing, QoS, IM, presence, emergency services, call control and a large number of others that could be labeled miscellaneous or infrastructure-based. And this total doesn't include the numerous SIP-related technical specification and implementation agreement documents developed by the ITU, ETSI, 3GPP and the Multiservice Switching Forum.Product developers who use SIP also have to face the fact that there is no "SIP certification" logo that would prove to the customer this is a SIP-compliant device or software product. SIP certification is problematic because SIP, besides being complicated, has limited error handling and fault management, and poor separation between service logic and call processing, along with no clear separation between the user-to-network and the network-to-network interfaces (UNIs and NNIs). In addition, multiple variants of SIP have been described to meet different market requirements. And all this adds up to interoperability issues.And SIP is Getting More ComplicatedIn November 2000, 3GPP chose SIP as the signaling protocol for the IMS architecture. Since then, IETF activity driven by 3GPP participants has shaped SIP into an IMS control plane protocol designed to mimic circuit-switched environments and to facilitate session control in the core of the network. That may have seemed like a good idea earlier in the decade, but since then, the complexity of the IMS platform and the net neutrality controversy surrounding IMS have not helped to make SIP any more popular.Meanwhile, SIP activity in the IETF is producing bigger SIP stacks and larger message sizes. This is the price being paid to "optimize" SIP for the major carriers to use so that they can:v service large populations of users andv bill them for all aspects of their Internet activity andv do so within a hierarchically controlled client-server structure.As SIP itself becomes more confusing, the IETF and the 3GPP have begun to disagree about how to save or extend SIP further, about which extensions will accomplish that, and/or which are most useful and/or most important, and/or which will give them a competitive edge. In short, the IETF and 3GPP have forked on SIP and are extending each fork of SIP into what could easily become incompatible telephony control systems.Product designers would rather not put multiple, complex SIP stacks in a product because of the design complexity, but also because of the potential impacts on processor, memory and battery life. Nevertheless, the Nokia dual-mode E60/61/70 WiFi/GSM phone comes equipped with two SIP stacks, one for the 3GPP standard and the other for the IETF standard. Will the end user be pleased or confused by having to deal with SIP configuration choices? Is this end-user value?Some mobile system operators have already had problems with the heavy bandwidth usage and other aspects of both SIP and H.323, and are instead using H.324M (a variation of H.324 for mobile phones). For example, SIP's unnecessary instructions and numerous messages can cause mobile devices to wake up and use precious radio and battery resources.Meanwhile, engineers grumble about SIP's bandwidth requirements and the number of messages required by its complex, per-call capability exchange. Most of these people know from experience that session initiation and VoIP can be handled more efficiently by other protocols. Some of them have downloaded Mark Spencer's Asterisk protocol and are also familiar with his published comparison of Asterisk IAX protocol to SIP, which concludes, among other things, that SIP uses more overhead, more bandwidth, more processing and more/larger messages.Everyone knows that complexity results in more issues and errors. Even if no one is saying it publicly about SIP yet, they will. Eventually, more developers will accept that SIP just doesn't do what needs to be done. Which brings us to the underlying question: Is it important that developers use some universal session initiation protocol? So far, the most successful Internet-based applications - P2P file sharing and instant messaging - have found it easier to build their own signaling protocols or use something else besides SIP.Who Really Cares About SIP?End users are not likely to care whether SIP or some other signaling protocol is underneath any of their multimedia activities, or that the versions of SIP they use interoperate - they just want the applications to work. And they usually can work around a lack of application interoperability pretty easily.For example, end users who have colleagues on several different IM systems might like to have an integrated display of all their buddy lists, but it probably isn't a high priority. By now they are used to running AIM, MSN and Yahoo, and all three at once when needed. Another option comes from the Web portal mash-up Meebo, a start-up that lets users chat over AIM, Google Talk, MSN and Yahoo all at once. Meebo further undermines the need for IM protocol interoperability.Application developers don't really care about interoperability with other applications either. Since the application developer makes the decisions on functionality and delivers the application, she is the best person to decide how to initiate, control and optimize application activity. If the application can handle its own session initiation, optimized to do exactly what it needs/wants and no more, or if the application can get the capabilities and controls easily elsewhere, why sign up for SIP's complexity, overhead and other burdens?Of course the SIP extensions are optional and can be negotiated at session initiation, but this adds complexity too. If it's a choice between struggling with SIP's complexity or more quickly getting to market with a proprietary product, guess which path most developers will take? The innovative developer's attitude seems to be: Why muck with all this complex stuff? I'll just initiate my session myself, my way.Some application developers also may bypass SIP in order to avoid potential snooping and controls from within the network. Following an easy-to-monitor SIP control/activity "template" would open the door to such snooping and controls, especially if and when deep-packet inspection and/or IMS are deployed. Why would Internet developers want to make it easy for their potential competitors to control their traffic and/or inspect their packet flows? Any information gleaned from deep packet inspection could help competitors improve their own services by exploiting defects in others.Arguably, a common protocol (SIP) on the server side would drive a single client software target, so a standard like SIP could be helpful to developers. The problem with this argument is that every application needs more than just SIP. For example, VoIP also needs the voice bearer and feature components and other software, and these can vary too. So, even if you want to solve the VoIP or multimedia interoperability problem, you won't do it using SIP alone.New Choices For Interoperability In the old days, interoperability mostly meant adhering to the same standards. Today, applications that run on IP can reach any endpoint IP address, just as those that run on HTTP can be displayed on any Web browser. This reduces the need for session and application interoperability, a need that is further reduced by the power and convenience of the modern desktop and its OS; users can run as many different programs as they like and toggle readily among them. Isn't it obvious that users and their applications don't need to interoperate by following a single protocol?Recently, there have been some moves toward interoperability of existing programs, but not with a common protocol: For example, in July of 2004, Microsoft, Yahoo and America Online forged an agreement for letting IM and presence information move between their IM services and Microsoft's then-forthcoming Office Live Communications Server 2005. The LCS 2005 would fulfill a bridging function to extend state data from one domain to another.Application developers are likely to see SIP as a complex control protocol that is optimized for telephony and laden with optional extensions and numerous flavors. If they have a simpler choice (as, for example, Google Talk's open Jingle protocol, which is based on XMPP), then why would they choose SIP?Remember, it was not the application developers who conceived SIP, or pushed SIP toward the goal of interoperable voice stacks. Rather, it was the standards developers, who seem to think that, by combining a bunch of services, each of which has very little usage, into the burgeoning SIP family, they will somehow drive the world to a common SIP, and that everyone else - including Asterisk, BitTorrent, Google, Microsoft and Skype - will eventually hop on board the SIP bandwagon. But what possible motivation could these successful services and their developers have to switch to SIP? ConclusionNone of the most popular emerging voice, data and new P2P applications uses SIP. Everywhere, developers are waking up to the fact that SIP requires difficult management, security and operation controls. Even operators and enterprise IT departments are not enamored of the complex product architectures that SIP requires in order to implement the simplest features. This is a major motivation behind H.325. Operators and enterprise IT departments want more granular feature control to better manage and control services.Is the IETF aware they may have extended SIP past the point of usefulness? Does the IETF fiddle while SIP burns and loses its appeal due to complexity creep and an increasing lack of use/interest by Internet developers?Building to the SIP protocol or having a SIP client just doesn't look very important. In fact, it may be far more important to allow devices to load all the clients they want and let the end user choose the service he or she wants. If you are going to maximize the value of the Internet to the end user, then you have to allow the end user access to all the varied and interesting applications on the Internet. This means the world will remain multi-client and multi-protocol, and SIP will not be successful in controlling it all.This article is reprinted by permission of BCR (www.bcr.com).

The last straw for SIP

News | 04/02/2007 12:55 am EDT

To keep reading, get a free trial.

Already a Subscriber?

Reuse & Permissions

Inside The Wire Report

Information

Hill Times Publishing

Get in Touch With Us