ABOUT THE AUTHOR


Alan Percy
Alan Percy is Director of Market Development at AudioCodes, a leading provider of Voice over IP networking products and enabling...
Read Full Bio >>
SHARE



Alan Percy | June 08, 2009 |

 
   

SIP Interoperability - Why Is It So Hard to Achieve?

SIP Interoperability - Why Is It So Hard to Achieve? The problem is that RFC 3261 that defines SIP has become "everything to everyone" and bloated in both size and in flexibility.

The problem is that RFC 3261 that defines SIP has become "everything to everyone" and bloated in both size and in flexibility.

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. The problem is that RFC 3261 that defines SIP has become "everything to everyone" and bloated in both size and in flexibility.

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 Shall = 4 Must = 631

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.The problem is that RFC 3261 that defines SIP has become "everything to everyone" and bloated in both size and in flexibility.



COMMENTS



September 10, 2014
Cloud solutions offer companies the unprecedented ability to forego the costly and painful process of updating their contact centers every few years in order to maintain some semblance of modernity, i...
August 27, 2014
Whether your organization has decided to move to the cloud, or you are considering the possibility, this webinar will help you cut through the all the "checklists" and give you four must-hav...
July 30, 2014
A myth persists that premise-based unified communications and contact center solutions are more secure than similar solutions in the cloud. Join this webinar to learn why that mode of thinking is outd...