SHARE



ABOUT THE AUTHOR


Alan Percy
Alan Percy is Senior Director of Product Marketing at Dialogic, responsible for marketing of the the company's media server and...
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 15, 2016
Over the past few years, unified communications has promised to improve employee efficiency and bring disparate communication modes together. But the end result has been vendor lock-in and limited fle...
August 24, 2016
The modern workplace has undergone significant change, and traditional ways of communicating and getting work done are no longer effective. These days, working smarter and more effectively is the diff...
August 10, 2016
Enterprises are increasingly considering Unified Communications as a Service (UCaaS) as the basis for their communications infrastructure strategy going forward. But some have been reluctant to commit...