August 1999

BY ROBERT VAHID HASHEMIAN

It seems like it was yesterday when we were introduced to H.323, the protocol that has been charged with giving us one thing and one thing only: Interoperability. Certainly the H.323 protocol has a rich set of features and functions that may seem to go way beyond just interoperability alone, but in the end, it was exactly the dream of a unified standard that has elevated H.323 into the limelight. Ratified by the International Telecommunications Union (ITU) in 1996, and then again in 1998 for version 2, H.323 quickly has become the buzzword for standard protocol in the world of Internet telephony.

The first time I heard of H.323 in 1996, I had no idea what it related to, and when I discovered its application in Internet telephony, I wasn’t sure if such a standard was really necessary. Back in those times it was very difficult to even imagine different Internet telephony devices interoperating. Every company in this nascent market was playing its own tune, and all end users got was a cacophony that basically drove away any notion of interoperability. This was of course to some degree understandable. Vendors had difficulty enough formulating their concepts of Voice over IP (VoIP) and surmounting its challenges using their own equipment, let alone having to interoperate with others. As a former TMC Labs engineer, I put a couple of these early VoIP devices to test myself. I specifically remember testing InterTel’s Vocal’Net, and V/IP gateways from Micom, now a Nortel Networks company. The products, as I recall, were pretty solid performers, but the notion of having my voice cross over from one brand of gateway to another did not even enter my mind. It seemed like an impossibility.

Fast forward three years, and Internet telephony interoperability is not only the dominating topic but something that end users will and should demand from vendors as they plan to cram their voice and data onto one circuit. Innovations in voice compression, quality, and delay management have catapulted VoIP into a fierce challenger to the traditional Switched Circuit Networks (SCN), while VoIP’s price advantage makes its cause for deployment a no-brainer. While we still have some more challenges to overcome in these areas to make VoIP indistinguishable from SCN voice transmission, the proverbial light at the end of the tunnel is clearly visible and getting brighter at an accelerated pace. But what about interoperability among VoIP devices?

THE H.323 CHALLENGE
Enter the H.323 standard, with an ambitious mission to tackle the VoIP interoperability issues. And we sure have a lot of issues on the table. Almost from its inception, every vendor you talked to claimed that they were H.323 compliant but all that didn’t amount to a hill of beans. I can’t think of a single solid success story substantiating the vendor’s claims. Sure, there were the occasional dressed-up releases, but the overwhelming feeling was that interoperability was an out-of-reach goal. All this made me think about the early days of the Internet and how it was developed to the successful platform that it is today. Imagine what the Internet might have looked like if IP was not developed and standardized across the board. Today, no matter which vendor you purchase your software or hardware from, if they are going to be on the network, they will be IP compliant. Every vendor who might have scorned IP at one point to the advantage of their adopted protocol, submitted to the market forces and embraced IP with open arms. Microsoft and Novell are two examples. NetBEUI (the networking protocol originally developed by IBM, was Microsoft’s networking platform while IPX/SPX was Novell’s. Both vendors eventually succumbed to the pressure and provisioned support for IP alongside their existing protocols. Today, I am willing to bet that most Windows and NetWare installations use IP (exclusively or in combination with the other protocols) for their network connectivity. Of course, if they are to be connected to the Internet, there is no choice but IP.

H.323 protocol is also going through a similar maturity process and getting better with every version. Traversing several layers of the ISO protocol stack, H.323 specifies the standards for audio, video, and data communications over IP-based networks. H.323 addresses devices on the network as well as control, session management, bandwidth management, and interfacing. It defines four components:

Terminals, Gateways, Gatekeepers, and Multipoint Control Units (MCUs).

• Terminals are the end-point clients within the architecture. Microsoft’s NetMeeting is an example, but these terminals are not necessarily computers. They may be any device such as a telephone, PDA, or others, so long as they support the relevant protocols.
• Gateways, which are optional in the H.323-based architecture, provide the translation between transmission formats. These translations can be between audio and video codecs, or packet and circuit traffic.
• Gatekeepers (also optional) provide two important functions. They serve as a central database for address translation between different clients. They also carry out bandwidth management (optional functions) for the network. For both of these functions, H.323 specifies that gateways use RAS (Registration/Admission/Status) protocol to regulate network use. Gatekeepers also are essential devices used to control cohesive groups of devices known as zones. The inter-zone communications between devices are established and controlled by the respective zone gatekeepers.
• MCUs support conferencing between three or more endpoints. Multipoint conferencing can be done in a variety of methods under H.323. H.323 also addresses a certain amount of discovery that must be done to determine common device capabilities for successful conferencing.

H.323 enlists a number of other protocols to achieve its end goal of interoperability. These include G.xxx for codec at the presentation layer (OSI model), Real-time Transport Control Protocol (RTCP) and H.245 at the session layer, Real-time Transport Protocol (RTP) at the transport layer, and Resource Reservation Protocol (RSVP) at the network layer, among others.

THE ALTERNATIVES
As complete as H.323 may have seemed in its initial version 1, there were serious holes in it such as inadequate support for compression schemes, no real security measures, and no Quality of Service (QoS) specification. Version 2 took a giant leap in addressing some of these issues. Arbitration of compression schemes, security, improved signaling, QoS, and improved resource management are among the number of improvements made over version 1. Yet there are still many areas where H.323 falls short in defining the standards. Many of these deal with gateway and gatekeeper control, management, and administration functions, leaving the vendors to devise their own standards to address these issues. One of the more well-known standards is Media Gateway Control Protocol (MGCP), which took its foundation from Simple Gateway Control Protocol (SGCP), developed by Telcordia (formerly Bellcore), and Internet Protocol Device Control (IPDC) developed by Level 3. Another protocol, Session Initiation Protocol (SIP), is promulgated by the Internet Engineering Task Force (IETF), and has gained acceptance from some of the Internet telephony vendors. There are also other standards that are being forged by vendors and organizations that we have yet to hear about.

While these standards help modularize and improve the overall network, they have introduced one nasty problem. Lack of interoperability. Some of these standards will find their way into version 3 of H.323, expected to be ratified in February of 2000. But for the meantime, the result has been a distorted and tainted image of interoperability that at best is patchy and ultimately impractical. I am not sure how this situation can be remedied. The Internet telephony vendors are on an accelerated pace of product development, but with each new product comes a new set of issues that the current H.323 standards do not address. So the vendors take the task upon themselves to define new standards. By the time standards organizations (e.g., ITU) adopt the new standards, next-generation devices are developed, and the vendors are busy working on the new set of standards. The vicious cycle continues. 

At the upcoming INTERNET TELEPHONY EXPO™ on October 6-8 in San Diego, CA, we are undertaking a worthy endeavor to have the exhibitors showcase their Internet telephony devices (software or hardware) on an IP-based network we call ConvergeNet. The underlying protocol is unimportant here (although we suspect H.323 and iNOW!, which is a superset of H.323, will be predominant). What matters is that ConvergeNet, with the help of the participating vendors and sponsors, will be the testing ground where the rubber meets the road and the various products are expected to interoperate. And perhaps in a small way, ConvergeNet can speed up reaching the ultimate goal of Internet telephony interoperability.

What do you think about ConvergeNet? Any ideas on how to break the vicious cycle that H.323 is caught in? Let me hear your voice at rhashemian@tmcnet.com.