June 1999

BY RICH BECKMAN

The elemedia Interoperability Lab was established to verify and demonstrate interoperability between elemedia’s H.323 Gatekeeper platform and the industry’s leading H.323 gateways and terminals. The lab, established in October of 1998, is focused on equipment using the H.323 protocol suite. As the voice-over-IP (VoIP) market and the elemedia product line evolve to include other protocols, the lab will also evolve to meet broader interoperability needs. The current scope of testing in the lab is on basic H.323 signaling and connectivity, and does not generally address surrounding issues such as billing and provisioning. In addition, elemedia plans to make the lab available (on a fee basis) to other vendors and/or customers who have interoperability testing needs.

LAB STRUCTURE
The Interoperability Lab provides an environment that can be used to efficiently test various H.323 gateways and terminals against the elemedia Gatekeeper platform. A number of H.323 gateways, terminals, and gatekeepers from different vendors are permanently located in the lab, and are available for various types of customized testing needs. Other gateways, terminals, and gatekeepers may be temporarily added to the lab for varying periods of time based on testing needs, and the lab has been designed for easy addition and removal of equipment from the test network. A Lucent Definity ECS PBX provides the telephony connections for all gateways, and can be configured to support a wide variety of telephony interfaces and protocols like T1-RBS, PRI, BRI, E1, EuroISDN, Analog LoopStart FXS/FXO, E&M, etc. An IP network provides connectivity among the various H.323 endpoints, and the lab has a structured dial plan that allows calls to be placed between any two gateways and/or H.323 terminals. Enhancements planned for the lab this year include the ability to simulate impaired IP networks and generate load-to-test if the level of product interoperability varies because of heavy traffic loads or poor network conditions.

Thus far, testing in the lab has involved a number of gateways and terminals from vendors including Lucent, Ascend, Cisco, MiBridge, Microsoft, and VocalTec. elemedia plans to add more gateways, as well as terminals and gatekeepers, in the coming months.

INTEROPERABILITY LESSONS
To date, the actual testing has been conducted by elemedia personnel, with support and cooperation from the gateway vendors in some cases. This support has included answering questions and providing equipment and/or software downloads. Testing of the various gateways is at different stages — i.e., some equipment has been in the lab for several months and other equipment has just arrived. Therefore, comparison among the gateways is not appropriate. Also, the charter of the lab is to foster interoperability and not to compare products against each other. However, the following are some high level points, as well as lessons learned:

• Full interoperability "out-of-the-box" is not quite a reality. Although the results are promising, there tend to be issues that arise with each combination of different vendor products.
• In the majority of cases, any initial issues that have arisen have been overcome, and baseline interoperability between the elemedia gatekeeper and a network of one vendor’s gateways has been achieved. Baseline interoperability is defined here as the ability to register gateways with the gatekeeper, and then place and clear calls using both direct-routed and gatekeeper-routed signaling models.
• Thus far, scenarios with the elemedia gatekeeper controlling a network of gateways from a single vendor have produced better interoperability results than scenarios in which the elemedia gatekeeper is controlling a network with gateways from multiple vendors.
• The treatment of alias information is a common area where issues arise. Two examples of this fact are as follows:

• In one case, the gateway placed alias information in a different part of the RRQ message than where the gatekeeper looked for it by default.
• In another case, the gateway was implemented such that it was assumed that alias information was always programmed centrally at the gatekeeper, and not transmitted from gateway to gatekeeper in the RRQ message.

In neither of these cases was the gateway non-compliant with H.323, since the terminal alias parameter in an RRQ is optional. Both are examples of how different interpretations of the standard prevented "out-of-the-box" interoperability. However, in both cases, baseline interoperability was achieved.

• In a limited number of cases, although the H.323 protocols are used by the gateways, testing has not been allowed to proceed because the gateway implementations are such that gatekeepers or other products from the same vendor are required to make the gateways work properly.
• H.323 version 2 was not universally deployed in the gateways. In theory, this should not cause any interoperability problems (other than preventing version 2 features). However, in one case it actually did prevent communication because the gateway would reject any messages from a version 2 gatekeeper. At first, a workaround for this issue was implemented. Later, version 2-compliant gateway software was loaded, and the problem was eliminated.

To understand how these conflicts were overcome, it is first necessary to give a quick overview of the elemedia Gatekeeper platform. The platform is a software package that enables rapid development of high-performance H.323 Gatekeeper applications. It includes a number of modules, and the core module contains the gatekeeper call control and registration functions. This core module interfaces with the other optional modules via a C++ API. The platform also contains policy and management modules, which provide functionality beyond the scope of the H.323 standard, and these modules can be customized or replaced. The elemedia H.323 Gatekeeper Software Platform is shipped with default policy and management modules that allow the application developer to build a "vanilla" gatekeeper out-of-the-box.

Testing began using the "vanilla" gatekeeper. When issues were discovered, they were resolved by customizing the policy and management modules, as could be done by a customer using the elemedia platform. No changes to the core modules have been required thus far. This fact is one of the most promising aspects of the interoperability results. The issues were not so fundamental as to require core changes.

WHAT IS NEXT?
Testing will evolve on a number of fronts:

• More detailed testing of non-mandatory H.323 features (e.g., the use of pre-granted admissions) will proceed for the gateways currently in the lab.
• New gateways will be brought into the lab for baseline testing, followed by detailed testing.
• Testing will expand to include terminals and other gatekeepers (i.e., multizone environments).
• Customized testing will be performed on a contract basis for vendors, network providers, and/or other industry parties with specific test scenario requirements.

The Interoperability Lab is available for demonstrations for visitors from inside and outside of Lucent, including customers, vendors and other industry parties. Additionally, vendors may contract with elemedia to perform testing with their products in the lab. Customers and vendors may also contract with elemedia to perform customized testing of particular multivendor scenarios.

Rich Beckman is a member of the technical staff for elemedia. elemedia, a wholly-owned subsidiary of Lucent Technologies, provides standards-based software for developing Internet telephony applications on a variety of platforms. elemedia products include the industry-leading H.323 Protocol Stack, Gatekeeper Platform, Gateway Platform, and compression technology for Speech and Video. For more information, visit elemedia’s Web site at www.elemedia.com.