August 2001

Interoperability Mania

BY JIM MACHI

To help answer that question, I interviewed Adam Altman, who for the last two years has been responsible for ConvergeNET at the INTERNET TELEPHONY� Conference & EXPO shows. I also spoke to Jeff Dworkin, who's responsible for the interoperability showcase at the Voice on the Net shows. We'll get to their thoughts in a moment. First, let's take an overview look at the various standards.

ALPHABET SOUP
As you probably know, H.323 was the first IP telephony call control standard -- available from the video conferencing industry when the VoIP industry emerged, since video conferencing used a LAN. Why reinvent the wheel when there was already something that worked? Actually, that thought process worked for about six microseconds. As soon as Internet telephony started taking off, the cry was heard for "better" standards. We needed "lightweight" standards, like SIP. We needed "scalable" standards that fit better with the telco distributed architecture world, like Megaco/H.248. And, of course, both the ITU and the IETF needed to stake a claim. H.323 was the ITU's answer; the IETF came up with SIP. And both bodies worked together on Megaco/H.248. Not to be left out, CableLabs came up with MGCP.

In the early days, the issue was simply whether one vendor's H.323 implementation (or gateway) would work with another vendor's H.323 gateway. It was (and still is) well known that one vendor could implement H.323 and call itself "H.323-compliant" but not work with the H.323 gateway from another vendor -- which also, quite rightly, marketed its product as "H.323 compliant." In fact, ITXC came up with the iNOW! (Interoperability NOW; currently overseen by the IMTC) initiative to instruct vendors to implement a "known" profile of H.323 so that interoperability might be achieved. Further complicating the H.323 picture is the fact that there are four versions, each more mature than the last. For example, the speed with which vendors implemented version 2 compared to version 1 was a major inhibitor to interoperability.

But these are no longer the early days. The wide variety of different call controls has led to geometrically increasingly complexity. Since we don't have a single call control, the potential exists for an H.323 gateway to try to talk to both a Megaco
gateway and a SIP phone -- right? Well, sort of. In fact, most networks have become H.323 networks, SIP networks, MGCP networks, or H.248 networks -- solving that problem automatically. And with the emergence of softswitches, which can act as protocol converters between the different call controls, this problem thankfully hasn't been a major one for the industry. Or maybe the softswitch vendors, who knew a hot revenue opportunity when they saw one, saw this trend coming. I remember the first softswitch companies, before they were called softswitches, offering these protocol converters.

So what do Adam and Jeff have to say about same-call-control-to-same-call-control interoperability? They have a unique vantage point since they manage interoperability events and know what really goes on behind the scenes. Both have seen improvements over the last two years, although Adam is quick to point out, "Not as much as I would have liked." He's really saying that there is not as much interoperability as the industry should have expected. For another viewpoint on this, I interviewed a contact at a large Internet telephony service provider, a major user of Internet telephony vendor equipment. Her only comment for publication? "Impossible dream." She's been personally frustrated by the slowness of interoperability.

This raises an interesting point. Is the lack of interoperability the vendor's fault? I've said in past columns that interoperability isn't inevitable unless service providers push the vendors by setting out interoperability requirements in their RFPs. Vendors who support open standards have led the interoperability charge. But what about the others? Is deployment and time to market more -- or less -- important than having fully interoperable (and therefore exchangeable) systems for service providers? I won't answer that question, since both points of view are valid. But that's one reason this issue is interesting.

At least we've seen improvements. Why? As Jeff points out, H.323 has matured and the "wiggle room" in the standard has been squeezed out through experience. "Experience" is a key word, since it suggests that the service providers are pushing the vendors to interoperate. I believe this has forced them to gain experience and work out the issues, driven by the potential for revenue.

Adam and Jeff also agree that the situation in the SIP community is better, since SIP is a lighter protocol and less complicated to implement. It's still not perfect, though. There can still be device configuration issues (for instance, one SIP device could use G.711, another could use G.723.1, and the two wouldn't be able to negotiate to a common codec).

But the bottom line is that we're getting there. It's slower than the hope -- and hype -- but it is happening.

Finally, you may be wondering why I used "mania" in the title of this column. Mania can mean two things according to my handy-dandy, well-worn, decades-old Webster's Collegiate Dictionary. One definition is, "excessive or unreasonable enthusiasm;" another is, "excitement manifested by disorganization of behavior." Which one describes the state of interoperability? It all depends on your point of view.

Jim Machi is Director, Product Management for the Intel Telecommunication and Embedded Group. The Intel Telecommunication and Embedded Group develops advanced communications technologies and products that merge data and voice technologies into a single network.

[ Return To The August 2001 Table Of Contents ]