Daily Payload
Home | News Archive | Search | Submit Story | Subscribe | Contact Us

Celebrating SIP's 10th Birthday (Part 2)

February 6, 2006

(continued from part 1)

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.