SIP Interoperability: Why Is It So Hard To Achieve (Part III)SIP Interoperability: Why Is It So Hard To Achieve (Part III)

How do we break the almost infinite cycle of continuous interoperability testing?

Last week we moved from a discussion about the technology and weakness of the SIP RFCs to what I feel is a far more difficult hurdle, the political challenges with SIP interoperability. As with national and global politics, getting people with diverse needs and existing investments to compromise is a significant challenge.So how do we break the almost infinite cycle of continuous interoperability testing between the growing number of hardware vendors, software applications and carriers? One approach that immediately comes to mind is to define a "gold standard" that each of the market participants can test against, and create a predictable level of interoperability assurance between systems. As one of my readers duly noted, this is the driving vision of the SIP Forum, and their SIPconnect effort, trying to make SIP Trunking interoperability more predictable. The SIPconnect Technical Recommendation 1.0 specifies the interface between a SIP-enabled Service Provider to a SIP-enabled Enterprise Network (aka "SIP Trunks"). The specification essentially narrows the hundreds of valid options within SIP to a defined set for one application, the replacement of legacy PRI circuits. So far so good, but don't get too comfortable quite yet. The down-side of SIPconnect (or any other interoperability standard) is as a side effect, it limits the services and options available to users of the systems. Think SIP handcuffs--great as long as you aren't the one wearing them. Features like security, network call transfers, voice messaging, fax, hosted PBX functions, dealing with NAT and other areas were in many cases outside the 1.0 specification and thus not supported. So back to the drawing board, extending the SIPconnect specification to 1.1, which is an ongoing development effort trying to add these important capabilities without ruining the simplicity of the 1.0 specification. But remember that SIPconnect is only focused on SIP Trunking and doesn't address interoperability between SIP systems within an enterprise or service provider. We've already seen cases where enterprises have one vendor for their SIP-based IVR and another vendor for their IP-PBX, and legacy TDM messaging systems, and are trying to integrate all these together. (Acquisitions and mergers have a funny way of making strange bed-fellows.) In this particular case, they couldn't even get the vendors of these systems to talk to each other, let alone actually fix protocol compatibility issues. With pure SIP-based applications expanding in market share and perfectly good legacy TDM systems that are too new to replace, I believe intra-enterprise interoperability issues will become much more common. In the end, I envision that enterprises will need a on-premise network element from an independent vendor that will provide interoperability and security between their legacy systems, SIP systems and SIP Trunks they depend on for connectivity. Right now, it appears a Session Border Controller (security and SIP interoperability) and/or a Media Gateway (TDM interoperability) is the best way to solve many of the difficult interoperability issues facing SIP. Trying to get competing vendors to talk seems to be an exercise in futility. Next we'll discuss who should be responsible for interoperability and security with SIP Trunking--the service provider or the enterprise?How do we break the almost infinite cycle of continuous interoperability testing?