The Internet Architecture Board (IAB), the arm of the IETF responsible for architectural oversight of the Internet, recently produced a fascinating document titled �What Makes for a Successful Protocol?� In it, the IAB looks at which Internet protocols have been relatively successful over the past ten years, which ones have been failures, and which ones have seen �wild� success. It then goes on to consider the factors that contribute to the success, failure or wild success of a protocol. Unsurprisingly, the biggest factors governing success are utility and incremental deployability.
It was satisfying to see SIP listed among the successful interdomain protocols. The very short list of other ones included IP itself, TCP, the Domain Name System (DNS) and the Border Gateway (News - Alert) Protocol (BGP). The set of wildly successful protocols is much shorter, comprising only IP and the Hypertext Transfer Protocol (HTTP). A wild success is defined as a technology that has gone well beyond its originally intended purpose, or well beyond its originally intended scale. HTTP clearly fits this definition, primarily in the area of intended purpose. As its name implies, it was conceived as a way to transfer hypertext from servers to clients. Today, however, it is the centerpiece of e-commerce; it has redefined distributed computing through the Simple Object Access Protocol (SOAP) and Representational State Transfer (REST), and it has become the universal firewall and NAT traversal protocol.
What is it about HTTP and IP that has made them not just successful, but wildly successful? I believe I know the answer. A technology becomes wildly successful when its infrastructure has the following two qualities:
1. It enables other people and other organizations to define completely new functionalities, without needing to change the protocols or the infrastructure itself.
2. It is sufficiently expensive that it would have been impossible to build just to support any given new functionality.
As a case in point, IP brought the ability for one computer on the Internet to send any kind of information to another. People and organizations could come up with new types of data to exchange (say, web pages), and they didn�t need to ask permission, didn�t need to change IP, and didn�t need to upgrade their routers. Furthermore, the cost of providing worldwide IP interconnectivity is so high that it is inconceivable to think of building such a network just to support one application (for example, e-commerce). This combination is why IP is not just successful, but wildly successful. Indeed, we are still seeing only the beginning of that wild success, as IP and the Internet continue to revolutionize market after market.
Of course, being focused on unified communications, this makes me wonder what it would take to make SIP technologies not just successful, but wildly successful. Let us consider both factors in turn, starting with the second.
Has SIP put into place an infrastructure that would be expensive to put into place for any new functionality? I think the answer is �not yet, but it will soon�. SIP�s primary goal is to initiate and manage communications sessions between users anywhere on the Internet. Unfortunately, we don�t quite have that functionality yet. SIP is widely deployed within individual islands � specific enterprises, specific providers � but is not yet globally worldwide infrastructure for connecting users no matter where they are. While it�s easy (relatively speaking) to build out the infrastructure within any one island, it is exponentially more expensive to build out a worldwide interconnected infrastructure.
What about the first factor, allowing users to do totally new things without changing the infrastructure? Unfortunately, we have more work to do there. SIP today is good at establishing specific types of sessions between users � audio and sometimes video. It supports flexible signaling, but new signaling functionality needs to be standardized, agreed upon, and built into various pieces of infrastructure. It�s not too late. SIP, as originally envisioned and specified, can be used to set up arbitrary sessions to exchange arbitrary data between users. It can, in principle, do so along the signaling channel (that is, through SIP dialogs) and through sessions it sets up. In essence, SIP could provide the ability to exchange arbitrary information between users anywhere in the network, in real time, without any changes to the SIP protocol or to the infrastructure that carries it. In a very real way, this represents an even broader set of functionality than HTTP itself provides.
The reality, however, is that Ds and enterprises are filling their networks with SIP elements that don�t support the level of transparency that SIP was originally designed to allow. These elements don�t allow arbitrary signaling and don�t support arbitrary sessions. If we reach a state of global interconnection, and that transparency is gone, we will have lost our opportunity. We will have turned SIP from something that could have been the next step in the evolution of the Internet, to just an IP version of a single-function network like the PSTN � useful for what it does today, but never useful for something more.
But hope is not yet lost! There is still time. If, as an industry, we are careful to allow SIP to reach its full potential, we can avoid that future. I, for one, am hopeful. I eagerly look forward to the day, 10 years from now, when I read the next revision of the IAB�s document on what makes a successful protocol and see SIP listed beside IP and HTTP as a wild success.
Jonathan Rosenberg is the co-author of SIP and SIMPLE. He is currently a Cisco Fellow and architect for the IP Communications Business Unit in the Voice Technology Group at Cisco (www.cisco.com).
Unified Communications Communications Magazine Table of Contents