In the United States, a wall socket delivers electricity at 120 volts, 60 Hz. In England they use 230 volts, 50 Hz. In Mexico they've "standardized" on 127 volts, 60 Hz. Even the shapes of electrical plugs vary across the globe. Don't expect to plug your North American cellphone charger into a Hong Kong wall outlet without using some sort of adapter.
The standard for digital telephone trunks in the United States is T1 (24 channels) while in Europe they use E1 (30 channels).
Here in North America 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 in the world and South America uses five of them.
So, why should SIP (Session Initiation Protocol) be any different? Why should you expect that Cisco SIP will natively interoperate with Microsoft, Cisco, Avaya, or Unify SIP? Other than because it's the right thing to do, you 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 vendors and things will generally work just fine.
Still, some vendors have taken liberties with SIP, and to paraphrase Frank Sinatra, "they did it their way."
So, what do you do when a Cisco Call Manager expects redirect information in a Diversion header and an Avaya Communication Manager insists upon putting it into the History-Info header?
You adapt.
Adaptation allows SIP telephones, call servers, applications, and trunks from different vendors to communicate with one another.
Adaptation can cure a number of ills. Sometimes the problem lies 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 type.
The problem might be in the body of the SIP message. For instance, Nortel put multipart MIME into the message body of an INVITE request and only a CS1000 could decipher it.
Finally, the problem might involve a combination of SIP messages and the VoIP media stream. For example, there are still products that use SIP INFO messages to carry DTMF tones, while the rest of the world follows the more correct process defined in RFC 2833/4733 which puts those tones into their own media stream.
Adaptation Tools
One of the most common places for SIP adaptation is a Session Border Controller (SBC). Most SBCs have tools that allow users to modify all parts of a SIP message. In the Avaya SBC, the adaptation tool is called STIM, in Sonus it's SMM, while Acme/Oracle uses a process they call HMR.
AudioCodes supports adaptation in two ways. First, it can be done on the box itself using inbound and outbound tables. Additionally, their latest software supports a REST API that allows external applications and services to perform SIP any required message manipulation.
As the name implies, an SBC sits on the border between two separate SIP domains or networks. This allows it to act as both traffic cop and SIP mediator. You will always find an SBC in the path of carrier SIP trunks. Typically, you will find two – one on the carrier's edge and another on the enterprise's edge.
Remote SIP endpoints out on the Internet will always connect to an enterprise via an SBC. In this case, think of the SBC as a SIP firewall that keeps the bad SIP traffic out and lets the good SIP traffic in.
An SBC can also be placed between different types of call processing servers within the same enterprise. I have even seen them used between a call processing server and an adjunct application such as a SIP-based voice mail server.
I have personally used an SBC to add a Diversion header to certain SIP requests sent across Verizon SIP trunks. This adaptation allowed numbers that were not provisioned in the Verizon DID (Direct Inward Dial) block to go through. Without the Diversion header, calls from those numbers were rejected. With the header, Verizon was able to accept the call and properly bill according to the diversion number.
Another source of adaptation might come from an enterprise's session management layer. I am most familiar with Avaya's Session Manager, and Session Manager allows adaptation modules to be inserted into the middle of call flows. For instance, Avaya supplies modules for calls to and from Cisco Call Manager. These modules can be applied to the ingress, egress, or both ingress and egress legs of a call. With the adaptation, Cisco is fooled into thinking it is talking to Cisco and Avaya is fooled into thinking it is talking to Avaya.
What about Nortel and its Multipart MIME message bodies? Session Manager has an adaptation module that removes the proprietary portions.
The last place for SIP adaptation is a SIP application server. Remember when I said that some vendors don't follow RFC 2833/4733 for DTMF digits? Avaya Aura Messaging accepts those nonstandard SIP INFO messages and processes them as if the touch tones came inside a properly formatted RTP stream. While this doesn't completely alleviate the problems that might arise from INFO messages, it's the difference between working most of the time and not working at all.
Taking it Home
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.
Don't let your train get stranded somewhere between Argentina and Brazil because you lack the proper rail conversion. Plan ahead for the nonstandard standards.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
