Messages and media

See correction below

ONE NICE THING about communications protocols is that there are so many. No matter what you want to do, you can find a protocol that will allow it. Of course, as new communications technologies are introduced, they are accompanied by even more protocols. That’s good if you’re introducing the technology, but confusing if you’re simply trying to make sense of your communications environment or, not so simply, actually trying to implement something.

One area where this confusion of protocols is notable is in CTI (computer telephony integration). For the last 15 years or so, vendors of CTI products have promised the ability to do nearly anything that could come out of combining a database and telephone. However, with the exception of call centers, where there has been significant success, a lot never got delivered.

A big part of the reason for non-delivery is a lack of standards about how calls are made, what devices involved with a telephony session can perform what tasks, what data goes with what call, and what data gets delivered to which device. Even operations such as how to put people on hold (a vital telephony function) weren’t always agreed upon.

Enter SIP, the Session Initiation Protocol. SIP is designed to do exactly what its name implies: to set up calls. Of course, this isn’t just for typical voice calls. SIP can handle nearly anything, from conferencing to multimedia to instant messaging and application mobility. SIP can take into account that the person trying to be reached may be mobile and may move from telephone to telephone. It can also take into account that the content of the call may change from moving across the Internet at one time to moving over a slow wireless connection the next.

In addition, SIP is designed to travel over the Internet using a text-based protocol that in some ways resembles HTTP. The SIP standard is being worked on by the SIP Working Group of the Internet Engineering Task Force, which will be responsible for publishing the RFCs (request for comments) that define SIP. Some of those RFCs are already out there, and there are more to come. For details, check out the Web site at www.sipforum.com .

It’s also important to know what SIP is not. It is not a transport protocol. This means that whatever content is being handled by the session that the SIP message initiates is being transported separately. All SIP does is set up the call and define its parameters.

But those parameters are very important. For example, you wouldn’t want a video call to be sent to a POTS (plain old telephone service) phone, but a voice call would work just fine. You also may not want to send such a call to a mobile phone, unless the person receiving the call has a third-generation phone. Then maybe you could.

One of the many things that SIP accomplishes is determining the capabilities of both the sending and receiving station, and handling the call requests accordingly. SIP also is capable of detecting presence, allowing it to report that someone is present on the network and available to receive, for example, an instant message.

Unlike earlier standards that arrived in the worlds of CTI and VOIP (voice over IP), SIP actually seems to work. The lessons learned from the HTTP world have helped a lot, as have the lessons learned from the failed standards of the past. But that doesn’t mean all is rosy. For example, SIP has problems penetrating some firewalls, as well as networks that use NAT.

The SIP forum has published work-around solutions to using SIP with NAT, but the solution to firewalls is a bit more complex. The problem is that firewalls may block SIP packets because they don’t recognize the protocol. This is being fixed as firewalls are being taught about SIP. In addition, not all firewalls have this problem, if only because SIP does resemble HTTP at some levels.

Other security issues aren’t so easily solved. Because SIP packets are in plain text, the routing, billing, and related information can be seen and manipulated by network snoopers. Malicious users could change the billing so that another station got stuck with the cost of the call.

According to Eran Wagner, vice president of technology at Santa Clara, Calif.-based Xacct Technologies, a SIP-enabled middleware vendor, SIP is badly in need of a standard means of encryption. He adds that SIP needs to address other security issues as well, such as the ability to bypass telco billing, or even to present inaccurate or fraudulent billing information to the telcos. He suggests that the SIP community needs a packet analyzer that can present trusted accounting information to the parties involved with carrying the call. Unfortunately, such a product has yet to be developed.

Meanwhile, a handful of vendors are already shipping SIP-enabled products. “We’re using it like people used HTTP 10 years ago — for everything really,” explains Scott Petrack, CTO of eDial, a Santa Clara, Calif., company that makes communications products, including the conferencing server he demonstrated during a recent interview. He explained how the touch tones that a user would press to enter a conference would be converted by the SIP interface into a URL, which would in turn connect the calls to the conferencing server.

So where is SIP headed? Probably to widespread adoption, unlike protocols that came before it. For one thing, the carriers of third-generation phones are using SIP for communications between switches. For another, it’s an open standard, so vendors can easily adjust their products to work with others, often quickly.

Despite a wobbly start, SIP is full of promise. For those of us still jaded from our experiences with the old CTI, SIP might be the antidote. For everyone else, it could be the kick-start that will finally bring computers, telephony, and the Internet together.

Return to the Special report: Future of telecom package.

Correction

In this article, we misreported eDial’s location. The company is based in Waltham, Mass.