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 15, 2009 |

 
   

SIP Interoperability: Why Is It So Hard to Achieve? (Part II)

SIP Interoperability: Why Is It So Hard to Achieve? (Part II) Let's move past the technical issues and talk about a far more difficult challenge--the politics of SIP Interoperability.

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

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 overworked 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 standoff 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.Let's move past the technical issues and talk about a far more difficult challenge--the politics of SIP Interoperability.



COMMENTS



December 3, 2014
Traditional SIP Trunking offerings have not evolved to keep pace with the modern expectations and requirements for the buyer. From painfully slow procurement processes, capacity limits, limited global...
November 5, 2014
With video collaboration expected to surpass email as the top means to communicate by 2016, organizational leaders are tasked with building flexible collaboration infrastructures that meet the demands...
October 22, 2014
As enterprises migrate from prior generations of communications technology into the future of Unified Communications, almost everyone has to deal with multiple vendors' systems. In the past, you would...