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



September 24, 2014
Distributed enterprises face a long list of challenges when deploying UC services to remote offices, including survivability, security and performance. IT managers need flexible and reliable solutions...
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...