Packetizer

Celebrating SIP's 10th Birthday
(PDF version)

February 2006 — It is hard to believe, but SIP is now a 10 year-old protocol. It's actually quite odd how some media outlets continue to refer to SIP as an "emerging" protocol given its age. It might be due in part to the enormous hype that has always surrounded the protocol. More than likely, it is simply that there has been little else to talk about, given that the telecom industry has remained in a slump for so many years.

Even with a lot of focus on the idea of a Next Generation Network, most of what 3GPP and the ITU have defined thus far has been nothing more than a formalized definition of interfaces and functions that use the SIP protocol. So, what's really "next" about NGN? What services are not available already?

Whatever the case, SIP is getting older, and implementations are now rolling out into the mainstream markets. Companies like Vonage and Packet8 have adopted SIP as the foundation for the services they offer to consumers. While these services have been relatively successful, one cannot help but think back to the late 1990's when SIP was on everybody's mind and great promises of "new kinds of services" were made. In those days, existing service providers were promised significantly lower costs, new service providers were promised the ability to deliver a host of new services that were never possible before, and everybody was promised a rapid service creation environment that would allow new services to be added to the network in a flash.

So, what happened?

It is now 2006, and carriers are still, by and large, offering the same basic voice services of yesterday. Only a handful of service providers are offering video, and we have not seen any new service providers rapidly turning out new kinds of services. {Ed - My VoIP service really has not changed in more than 2 years. }

There are a number of reasons one might give as to why SIP has, to this point, failed to live up to the hype that propelled it in the late 1990's and sustained it through the first half of this decade.

We assert that there are really two very fundamental reasons why SIP has failed to live up to the hype surrounding it for the past 10 years and both are about money.

First of all, users expect to get more and still pay the same price. The cost for a carrier to switch from PSTN-based technology to VoIP technology is relatively expensive and the return on investment simply is not there. Now, that is not to say that carriers will not switch: they absolutely will, because IP is universally agreed to be the network for all future services. Even so, carriers do not feel a sense of urgency to replace perfectly working gear for something that may not work so perfectly. (There are many, many issues that one uncovers as one explores a migration to VoIP, so we will not go into detail in this article.)

The second reason why we have not seen a mass movement to SIP so far has to do with potential revenue from services. If service providers felt that offering VoIP services would quickly add new revenue-generating opportunities, they would move much more rapidly. However, that promise has not been fulfilled. Rather, we are now seeing very complex IMS-based systems being defined, which effectively put the carriers into the same position they were in with TDM-based networks.

Back in 1999, service providers voiced complaints to the VoIP protocol designers that steps must be taken to allow service providers to deliver new services and to control services without requiring users to upgrade equipment or to utilize services that bypass the service provider's network. The protocol designers did not listen. Instead, all of the service logic for any new SIP service is added right into the telephone. Basic call features like call hold, call transfer, and call park are programmed in the phone. This introduces a huge operational cost for service providers that want to introduce a new service, as every supported SIP device on the network must be tested with any new service and users will necessarily have to install new firmware or, in many cases, buy a new telephone to take advantage of any new service.

This leaves service providers with very few options, including limiting the number of SIP devices that it supports, simply refusing to offer new services, or refusing to even support serves that are resident in the user's telephone already. If your call transfer does not work, don't complain to your service provider: it might be your telephone, the service provider, or both who have some problem. Troubleshooting the problem is more expensive than it is worth to the service provider.

New VoIP consumers have complained that the choice of SIP devices is limited or that they must buy new devices if they change service providers. This is likely not going to change as long as service providers remain focused on SIP. Service providers do want to provide and support services, so the only valid choice is to tightly control what kinds of devices it will support.

With all of this talk about service providers, what about enterprises? They face the exact same issues: introducing new services in a SIP-based network means upgrading all of the different SIP devices installed on the network. That can prove to be a very expensive exercise for larger enterprises. It is no different. Just imagine an enterprise with 50,000 phones from 15 different vendors purchased over 10 years: trying to add a new service to a network like that would be virtually impossible.

Perhaps the industry has taken a wrong turn? The things that service providers wanted were not delivered. Enterprise customers are looking for lower cost of ownership, not added complexity or higher cost.

What may be needed is a truly "next generation" protocol that separates service control from call control. Perhaps we need a protocol that provides the right balance between simplicity and functionality. Perhaps what we need is a protocol that gives the service providers and enterprises around the world with a tool that really does enable them to rapidly create new services and deliver those services without introducing huge costs.

Happy 10th birthday, SIP. Where will we be in another 10 years? Perhaps what we need is not SIP.