June 2009 Archives

 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"?   What happens if you or anyone else makes changes?  Do you re-test with everyone?  It was easy when there were just a few other applications to test with on the market, but now with hundreds of applications and devices to test, it becomes clear that the maintenance of SIP interoperability testing becomes a bigger burden than the original development. 

 So, how do we work around these political problems and break the cycle of continuous interoperability testing?  This will be the topic of my next post. 

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. Continue Reading...