X
Innovation

SIP is the future of telecommunications

As was clear from last week's ITEXPO in Los Angeles, SIP is shaping up to be the standard replacement protocol for the traditional TDM / SS7 network. SIP trunking starts to make it possible to offer an end-to-end digital communications solution that can call any number in the world...without a traditional phone line anywhere in your organization.
Written by John Carroll, Contributor

The 18th Internet Telephony Conference & Expo (ITEXPO) came to Los Angeles last week, and being the opportunistic sort, I decided to get myself on the press list. That's one of the advantages of writing for ZDNet. Conference organizers will often let you attend their creation for free in hopes that you might write something about the products on display therein.

I'm not, however, one of those writers who likes to post a play-by-play of the happenings at this or that conference. I prefer to attend the entire conference, visiting all the classes and study groups which, to my mind, serve as the highlight of such things, only to figure out afterwards what new thing I have learned from the whole process.

I did note that this was the 18th ITEXPO...which means that there were companies thinking about a future where communication was entirely mediated by Internet-related protocols as far back as 1990. In 1990, the notion that a web of connections mostly linking academic institutions might serve as the foundation underpinning something as critical as voice communications must have seemed, to some, like so much technophile hyperventilation. Clearly, however, the Internet has been more than a little bit succesful. Furthermore, protocols designed to run over Internet connections seem to be reaching a tipping point with respect to their adoption by telecommunications companies. I'm not just saying that because I am still responding to the "reality distortion field" caused by the strange chemicals conference organizers insert into their continental breakfasts. Looking back, most of my career seems to have been spent working for one telecommunications company or another (though video-related work seems to have occupied most of the rest).

One thing that has already been rolling along for quite some time, but has become extremely apparent given recent developments in the industry, is that Session Initiation Protocol (SIP) isn't just a protocol that is "popular" in Voice over IP (VOIP) environments. It is, for all intents and purposes, THE VOIP protocol, at least among traditional telecommunications providers. It is the protocol that networks choose when they want to IP-enable their largely SS7 environments (SS7 is the signaling protocol used in the global circuit-switched network used to communicate within and between almost every telecommunications company in existence). SIP plays a central role in the IP Multimedia Subsystem (IMS), a family of protocols which is supposed to define the architecture of next-generation mobile networks capable of streaming various kinds of text, voice and video data to mobile phone subscribers even as they roam between networks.

Though the people at the conference were clearly fans of an IP, and SIP-based, future, nobody believed that SS7 was going to go away tomorrow. The existing investment in SS7 is massive, and telecommunications companies aren't going to replace overnight a technology into which they have sunk many billions of dollars in investment and which reliably serves the voice communications needs of the entire world. However, as we move beyond a network mostly built to cater to the needs of voice, SIP is simply a more flexible alternative.

Session Initiation Protocol (SIP) is, at least syntactically, a lot like HTTP. It confines itself to simple negotiation of data streams between endpoints, and doesn't impose any kind of rules as to the nature of those data streams (though streams of data are usually packaged inside RTP, another publicly-ratified protocol). SIP, in other words, can be used to negotiate a voice connection, as well as exchnage text message of varying sizes and complexities, exchange presence information, and exchange any kind of data the nature of which can be described via MIME headers and the protocol details for which can be described via Session Description Protocol (SDP, which is exchanged as part of SIP negotiation). SS7, in theory, can be used to negotiate multiple kinds of data streams as well, but the history of the development of the traditional phone network means that most endpoints can, at most, handle basic audio encoded according to G.711 rules (a limitations of the vertically-integrated switch hardware that was the norm for most of telephony product history). Further, though SS7 is a simple signaling protocol as well, it doesn't have the level of expressiveness and flexibility as a text-based protocol like HTTP or SIP.

HTTP has proven to be one of the most popular media exchange negotiation protocols in existence. SIP borrows many of those semantics, and makes media exchange negotiation more flexible still.

But if I don't dive deep into a blow-by-blow description of the intricate details of the SIP protocol Right Now, knowledgeable readers will pillory me for being excessively vague. So, I will stop here, and note that you can find stacks of documentation about the SIP protocol on the Internet and / or books published by any number of publishers. That's the magic of a public and officially-ratified protocol. There's no real mystery about its details.

Of particular note at this conference, however, was the emphasis on the concept of "SIP trunking." Traditional TDM trunking is often via a T-1 / ISDN PRI connection. T1 connections are ridiculously expensive ($500 / month is not uncommon, and it used to be much more), particularly when you consider that they only provide a maximum bitrate of 1.544 mbps over the 24 unique voice / data channels a T1 provides, each of which runs at 64 kbps (the European equivalent, E1, gives you only a bit more, at 2.048, with 30 voice channels). Given the bandwidth limitations of TDM trunk connections, few businesses would use a T1 or E1 link for anything but their voice communications.

This makes T1 connections an extra expenditure on top of digital data links. Further, there is a translation step for many businesses using modern business telephony products, many of which use SIP as a means to communicate between telephony endpoints within the business. A far cheaper and flexible way to achieve your office communications needs would be to dispense with that TDM connection entirely and use that data channel as conduit for all of your communications.

SIP trunking allows you to do that. By paying for a SIP trunk connection, you don't need to have any kind of phone line hooked into your office. You just pay for a SIP connection from the SIP trunk provider of your choice, and your SIP-compliant software has all the telephony connectivity it needs.

One of the advantages of this model is that you aren't tied to just a number in your local area or country. Given that SIP abstracts away the concept of where you are, it is easy to have numbers in multiple countries that feed back into your central office. This gives small companies the ability to seem like much larger companies, something from which my company, which is extremely small, could certainly benefit, but from which even home users can benefit. SIP trunking also allows you to escape reliance on the owner of the phone or cable lines that run into your home for voice service, moving beyond cable-based VOIP services, and even consumer services like Vonage, to allow a web of VOIP providers to compete for your home phone business. Though that wasn't the emphasis of the conference, which still focuses on the needs of the enterprise and call centers, the writing is clearly on the wall. SIP trunk connections are likely to find their way into end-users homes once businesses - a group that serves as the canary in the mine for most new technologies - have worked out the kinks.

Tomorrow, I'll talk about a product I saw at the conference that, at first blush, I wasn't sure I would find interesting when first invited to speak to the responsible parties. That product just so happens to come from Microsoft...and no, it isn't Office Communications Server (OCS).

Editorial standards