SIP Adaptation

The trouble with standards is that they rarely are. Standard, that is. It seems that no matter what sort of technology you are dealing with, there are plenty of variations. In America a wall socket delivers electricity at 120 volts, 60 Hz. In England they use 230 volts, 50 Hz while in Mexico they’ve “standardized” on 127 volts, 60 Hz. Even the shapes of electrical plugs vary across the globe. The standard for digital telephone trunks in the United States is T1 while in Europe it’s E1. Here in Minnesota we drive on the right side of the road while in Japan they drive on the left. And don’t expect to drive a train from Brazil to Bolivia. There are eight different gauges of railroad track and South America uses five of them.

So, why should SIP be any different? Why should you expect that Cisco SIP will fully interoperate with Microsoft, Nortel, Avaya, or Siemens SIP? Other than because it’s the right thing to do, you really can’t.

However, all is not lost. SIP is controlled by the Internet Engineering Task Force (IETF), the same people that develop and control the protocols used to run the Internet, and for the most part their documents and recommendations are faithfully followed. You can build a system comprised of SIP services and devices from different companies and things will generally work just fine. Still, some companies have taken liberties with SIP and to paraphrase Frank Sinatra, “they did it their way.”

So, what do you do when Cisco Call Manager expects redirect information in a Diversion header and Avaya Communication Manager insists upon putting it into the History-Info header?

You adapt.

Adaptation

Adaptation allows SIP telephones, call servers, applications servers, and trunks from different vendors to communicate with one another. Adaptation can cure a number of ills. Sometimes the problem is in the SIP headers. One vendor might expect data in one header while another vendor puts that data into a different header. It’s also possible for a vendor to require data that another vendor doesn’t send regardless of the header. The problem might be in the body of the SIP message. For instance, Nortel puts multipart MIME into SIP message bodies and no one else in the world understands what to do with that. Finally, the problem might involve a combination of SIP messages and the VoIP media stream. For example, Cisco uses SIP Info messages to carry DTMF tones, while most of the rest of the world follows RFC 2833 which puts the tones into RTP data. Depending upon the problem, SIP adaption occurs at different places in an Avaya configuration.

Session Manager

Let’s start with the Avaya Session Manager. Among the many tasks that a Session Manager performs, it has the ability to assign Adaptation Modules against specific SIP Entity Links. For example, a SIP Entity Link assigned to a Cisco Call Manager would use the module CiscoAdapter to ensure that the Cisco system understands the SIP messages sent to it and the non Cisco systems understand the SIP messages coming from that link.

Session Manager Adaptation Modules are static in nature in that they do not permit processing outside the modules to do their job. In other words, an Adaptation Module cannot reference a database or external service to perform the adaptation. It’s important to know that Session Manager Adaptation Modules can only be written by Avaya. If you have a need for SIP adaptation that is not satisfied by an existing Adaptation Module, you need to go a different route.

Sequenced Applications

The next available place for adaptation is a Sequenced Application. Like Adaptation Modules, Sequenced Applications run in conjunction with Session Manager, but unlike Adaptation Modules, Sequenced Application are extremely dynamic and can be written by anyone. A Sequenced Application can add SIP headers, change SIP headers, remove SIP headers, and change the SIP message body. Sequenced Applications are developed with ACE and the Foundation Toolkit.

Session Border Controllers

The next important place for SIP adaptation is a Session Border Controller. Most SBCs have an adaptation layer similar to that of Session Manager, but unlike Session Manager, that layer comes with a user accessible configuration tool that allows for the creation of new adaptation modules. In the Avaya/Sipera world that tool is called STIM while Acme uses a process they call HMR. In all cases, these tools create static adaptation modules that do not reach out to other services or databases to perform their adaptations.

Elsewhere

The last place for SIP adaptation is a SIP application server. Remember when I said that Cisco doesn’t follow RFC 2833 for DTMF digits? Avaya Aura Messaging accepts those non standard SIP Info messages and processes them as if the touch tones came inside the RTP stream. This allows for interoperability without having to somehow pull those digits from the SIP packets and stuff them into a G.711 audio stream.

Make it So

So, even though the SIP “standard” might not be as standard as we would like it to be, there are several ways to create a network of SIP devices that peacefully coexist. This is the key to opening up your communications environment to applications from different vendors, trunks from different providers, “Bring Your Own Device” endpoints, and call processing systems of all shapes, sizes, and colors.

Now, if only someone would come up with a single cell phone charger for the one million or so different cell phone models out there. That’s one standard that I desperately want to see come to light.