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 wasnt 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 InterTels
VocalNet, 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 VoIPs 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
didnt amount to a hill of beans. I cant think of a single solid success story
substantiating the vendors 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 Microsofts networking platform while IPX/SPX
was Novells. 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.
Microsofts 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
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,
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.
Robert Vahid Hashemian provides us with a healthy dose of reality each month in his
Reality Check column. Robert currently holds the position of Webmaster for TMCnet.com your online resource for CTI, Internet
telephony, and call center solutions. He can be reached at email@example.com.