[November 22, 2005]

Interoperability -- Why Isn't It Working?

By Tracy Venters

Vice President, Solutions Engineering, tekVizion PVS, Inc.

Someone once said, "The great thing about standards is there are so many of them."

This tongue-in-cheek remark reveals the ambivalence many telecom products vendors feel about standardized protocols. Although some developers complain that following a set of standards, such as SS7 or SIP, limits their ability to build truly differentiating products, in theory standards should allow products between different vendors to work together in a plug-and-play fashion, thus providing carriers with the freedom to build a best-of-breed network exactly suited to their individual needs.

In theory.

It is no secret that SIP is anything but plug-and-play. Interoperability of SIP-based products - or lack thereof - is a major factor in the rollout of VoIP services, often causing delays in initial service deployment or network upgrades. Each component must be tested and certified for interoperability with the service provider's network, a process that must be repeated with every software revision. But if SIP is a standard, why is interoperability such a big deal? What is causing the lack of interoperability?

The fact that SIP is still evolving, and will continue to do so for quite some time, is one of the leading causes of non-interoperable products. Hundreds of drafts related to SIP have been submitted to the IETF over the last few years. Some make it to the request-for-comments (RFC) stage and the rest end up in the "morgue," but along the way some vendors will embrace and implement these drafts to varying degrees.

SIP is described using ordinary language (which is often touted as a good thing). However, this leaves the standard open to interpretation. For example, one of the sections of RFC3261 says an implementation "needs to take care when forming requests directly from a URI." What is meant by "take care"? If an inappropriate header field is received, should the implementation reject the request, attempt to fix it, or ignore the bad parameter and continue to build the message?

Even when the language is clear, implementations may be flawed or incomplete. For example, in a rush to get products to market, some vendors skimp on testing (and coding) for negative cases. A product may work fine in a perfect world but goes belly-up in certain instances. These "certain instances" may be something as simple receiving an INVITE message when expecting an ACK.

Another cause of non-interoperability is the flexibility the standard allows. For example, the standard supports three different ways to collect DTMF digits. As if that isn't enough, some vendors have even come up with their own proprietary methods of digit collection to add to the mix.

In addition to finding proprietary ways to do things like collect digits, vendors often add extensions in order to provide a differentiating feature or function. After all, that is another much-touted benefit of SIP - its flexibility in supporting the exciting new multi-media services not yet thought of or devised.

Should we stifle innovation for the sake of strict standards? Not at all. There are steps vendors and service providers can take to prevent unreliability caused by interoperability issues. In some cases vendors and service providers with common interests have come together to define implementation agreements, which are essentially a "standard within a standard." Outside of formal implementation agreements, any two vendors working together must agree on the rules of engagement.

Finally, however agreement is reached on what and how to implement to support a set of features, thorough interoperability testing must be done any time any component in a solution is upgraded to a new software release. This preventative measure will help ensure today's SIP-based networks are as reliable as the old PSTN.

_________________________________

As vice president of solutions engineering for tekVizion PVS, Inc., Tracy Venters leads the company's solutions architecture team. In this role, she is also responsible for all pre- and post-sales support efforts as well as technical marketing.

tekVizion (www.tekvizion.com) has set the new standard for systems integration in the telecommunications industry. Its core services include consulting, custom applications, integration and support, and testing through tekVizion Labs -- the first interoperability certification lab of its kind. tekVizion Labs offers a full suite of testing services, including interoperability, solution, conformance, product assessments, and outsourced testing. tekVizion helps service providers achieve a smooth transition to packet-voice networks, speeding delivery of integrated servic

[ Back To TMCnet.com's Homepage ]

Discussions: