June 2009

Earlier this week I shared with you a few thoughts on SIP Interoperability discussing what I felt where the root causes of incompatibility between two or more SIP-based systems. I clearly hit a raw nerve with a few of you, flooding my email box with your own stories of interoperability issues. You shared with me your own experiences with registration problems, call transfers, security, message waiting indications, even fax issues. It seems the couple examples I gave were only the tip of the iceberg.

Let's move past the technical issues with SIP Interoperability and talk about a far more difficult challenge - the politics of SIP Interoperability.

It appears to me that soon after the authors of RFC 3261 finished their work, the fun really started. As the development teams of the various product and application companies started to build their solutions based on RFC 3261, the looseness of the specification allowed them to make wildly different choices all "within specification". The result was that you had developers that had invested untold hours of hard work into developing a protocol stack that worked fine in their own lab and with their own products, but had serious interoperability issues with other vendors. To each of the developers, it appeared that "everybody else screwed up".

So now you have a number of over-worked developers that would have to go back into their products and re-work significant parts of their SIP stacks - just because someone else made some bad choices. The end result is a classic stand-off with each of the vendors saying "we followed the spec, you should change". So much for "Open and Standard".

To make things even more politically complex, many of the vendors are starting to compete in the marketplace, vying for the same markets and customers. In this competitive environment, interoperability is a double-edge sword.

Okay, so let's pretend our developers get past their own stubbornness and decide to make some changes to be more interoperable. Who do you do your interoperability testing with? Do you test against anyone that comes along? Or maybe just in cases where "the business case works"?

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.