Understanding H.323�Part IV: Testing System Interoperability

Tuesday May 10th 2005 by Mark A. Miller

The quirky evolution path taken by H.323 and related standards makes for some serious implementation challenges. Fortunately, there are tools to help.

In our previous three tutorials on the H.323 standard—developed by the International Telecommunications Union–Telecommunications Standard Sector (ITU-T) to support multimedia communication—we explored the history and architecture of that standard, and the various protocols that are required to support the terminal functions, and how H.323 signaling is used to establish and disconnect H.323 connections. In this tutorial, we will consider some of the interoperability issues that need to be addressed for a successful H.323 implementation, and some of the guidelines that have been developed to assist network managers with that implementation challenge. Let's begin with a brief history lesson for anyone that has not been through a multi-vendor interoperability war.

When local area networks (LANs) became popular in the early 1980s, there were two network standards: Ethernet, developed by Digital Equipment Corporation (DEC), Intel Corporation, and Xerox Corporation, (collectively known as "DIX"), and the IEEE 802.3 standard developed by the Institute of Electrical and Electronics Engineers (IEEE).

The DIX Ethernet standard was developed first, and then subsequently handed off to the IEEE, who used it for a baseline for the development of the 802.3 LAN standard. As one might expect, the IEEE saw room for improvement in the earlier Ethernet work, and made some changes that affected both the electrical (hardware) interface, and the protocol (software) operation.

Forecast: cloudy
As a result, workstations adhering to the earlier Ethernet standard were not likely to be able to communicate with the newer IEEE 802.3 standard. To make matters even more complicated, enterprising vendors took it upon themselves to tweak either of these standards to gain an advantage over the rest of the crowd. For example, one vendor would boost the output drivers at the transmitter, and therefore permit a longer run of cable between workstations. This may have given them a leg up on the competition, but it didn't make the network management job any easier, as a mixture of Ethernet-compliant and IEEE 802.3-compliant workstations might not work together on the same LAN. If you throw in a mix of vendors, some of which have strictly adhered to the published standard, and others that have tweaked it for marketing advantage, life for the network manager got even more complicated.

The industry response to these earlier interoperability wars was to develop consortiums of interested parties, including product developers, manufacturers, network managers, and end users, that would participate in the development of multi-vendor interoperability test suites. After that test suite had been developed and preliminarily tested, vendors were invited to a central location to test their products on the same network, and alongside those of their competition, and see who could communicate with whom. In most cases, the results of these tests remain proprietary to the participants, with the idea being that the information gleaned will be used to correct, modify, or improve products, not bash the competition.

As we have seen in the previous tutorials, H.323 is actually a suite of standards, with a number of elements under the H.323 "umbrella," including the ITU-T H.225.0 and H.245 standards, reliance upon the IETF Real Time Transport Protocol (RTP), and other Internet-derived protocols, plus audio and video encoding standards such as G.711 and H.263. For example, if your video conferencing system won't communicate with my video conferencing terminal, is it my fault or yours? Is there a problem with the signaling parameters that are attempting to establish the call? Is my audio codec, plus all of its parameters, compatible with yours? What about the data and video side? Are we operating at the same transmission rate, and with compatible protocol parameters? As you can quickly conclude, the interoperability challenge with these multimedia systems could be an order of magnitude more challenging than the earlier days of Ethernet vs. IEEE 802.3.

Help on the way
Fortunately, some well thought out plans have been crafted by a trade group called the International Multimedia Teleconferencing Consortium (IMTC), that are available to guide the industry through this interoperability jungle. The IMTC is an organization of ISPs and application developers, equipment vendors and telcos, end users and standards organizations, plus any other party interested in making sure that these complex multimedia systems can actually communicate with each other. The IMTC organizes interoperability testing events several times per year, which are open to interested product developers. Of perhaps more interest to network managers is the H.323 Interoperability Test Plan that the group has developed, and which is available at www.imtc.org/interops/test_plans/CoIP-H323TestPlan6.zip. This plan details seven different testing scenarios that can be used to verify H.323 system functionality. Testing scenarios are defined for configurations with and without Gatekeepers, with and without Gateways, and with and without firewalls—in short just about every configuration that you are likely to encounter on your enterprise network. Also included is a scoring page, in spreadsheet form, that allows the tester to keep track of results.

Granted, the test scenarios are more aligned with product developers than network managers, but they are quite useful in planning your H.323 deployment. Just reading over the various testing configurations will give you a greater appreciation for the complexities involved, and help higher level managers understand why the interoperability questions need to be investigated when you are building a small test network, not deploying a multimedia system to thousands of end users. The IMTC has gone a long way toward solving the interoperability challenges of the 1980s. Wise network managers will leverage their research and avoid headaches for themselves.

Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved

Author's Biography
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved