For those of you that have deployed SIP-based solutions or SIP Trunking, there is a pretty good chance that you've had to navigate your way through the maze of SIP interoperability, wondering why it is so difficult to get a straight answer out of anyone on whether two systems will work together or not.SIP is supposed to be a standard and eliminate many of the challenges with integrating systems from various vendors together, right? If my IP-PBX is RFC 3261 compliant and my SIP Trunking service provider is RFC 3261 compliant, they should just work, correct? Well--maybe or maybe not. Most likely there will be interoperability issues.
Today I thought it would be good to start a multi-part series of posts to explore why SIP interoperability seems to be as challenging as it appears, how the vendors are dealing with it and solutions you can use to solve difficult interoperability challenges.
The Root Cause Let's start with a discussion on the root causes that make SIP interoperability difficult. The problem starts not with technology, but with the way that IETF Requests For Comments (RFCs) are developed. As opposed to the old ITU specifications that the Telecommunications Industry has lived with for the last four decades, IETF RFCs and Drafts are developed in an open and communal environment, using committees and consensus to craft the specification. This has very many positive benefits, but also a few predictable negative side effects.
Performing a simple word count on RFC 3261 yields some interesting insight into the problem: Weak Terms May = 381 Should = 344 Option = 144 Can = 475
Strong Terms
Strong Terms
As you can see, the number of weak terms "May," "Should," "Option" and "Can" outnumber the stronger "Shall" and "Must," which results in a very loose specification that allows the developers of SIP-based systems to make plenty of decisions on features of functions. The byproduct of this is that two systems can be completely RFC 3261 compliant and completely incompatible.
Examples In our experience, there are no fewer than five "correct" ways to transport DTMF tones from one end point to another: * In-band--leaves the DTMF tones in the RTP streams * RFC 2833--uses specialized payload packets in the RTP stream to indicate a DTMF tone * SIP NOTIFY--uses a SIP message to indicate the presence of a DTMF key press * SIP INFO (Nortel)--a technique frequently used in Nortel systems that uses a SIP INFO message * SIP INFO (Cisco)--a variation on the above, but with some slight modifications.
Another example that is causing a lot of grief right now whether to transport the SIP messages over UDP or TCP. The RFC indicates that either is okay and recommends supporting both, but few manufacturers actually do support both. The vast majority of equipment and application developers chose SIP-over-UDP. Microsoft chose SIP-over-TCP. Again, both are within specification and completely incompatible.
While these technical challenges may seem difficult to overcome, they can be solved. However, the political issues are another story. I'll discuss these in the next post.
