H.323 Global Network Config Guide

*** This document is a draft and undergoing heavy revision ***

Introduction

This guide describes how to get connected to the H.323 Global Network (HGN). Connecting to the HGN requires certain feature support in the connecting H.323 equipment, all of which is discussed below. When connecting an entire network, such as an enterprise network or service provider network, administrators will need properly configure DNS settings, Gatekeepers, and ensure that a compatible NAT/FW device is employed. This guide provides administrators with all of the necessary information in order to successfully interconnect with the HGN.

This guide is intended for network operators, enterprise IT staff, and others who wish to configure their equipment to interconnect with the HGN. End users who just want to get their softphone or videoconferencing system working with the HGN should create an account on h323.net and follow the instructions on the user account page.

Note that this guide is updated from time to time in order to reflect changes in the HGN and to consider special configuration settings for certain equipment or topologies. However, it is the objective of the H.323 Global Network Project to ensure that any such changes will not result in breaking interoperability with devices that are already deployed and conforming to the HGN requirements.

Interconnection Requirements

To connect to the HGN, you may use a wide variety of H.323 hardware or software products. However, the point of interconnection must adhere to very specific requirements. If your H.323 products do not support these requirements, then you may need to utilize a Gatekeeper, such as the freely-available GnuGk, to provide the necessary signaling support. Or interconnect your equipment with a service provider who can provide the proper support you need.

All devices or networks interconnecting with the H.323 Global Network must support:

H.323v4 or higher
NAT/FW traversal standards H.460.18, H.460.19, H.460.23, and H.460.24
H.245 tunneling
G.711 for voice
H.263 for video

It is recommended, but not required, that devices support H.264 for video and this may become a requirement at some point. Unfortunately, licensing restrictions do not permit open source products to use H.264 at the moment without paying fees that clearly cannot be paid by developers of free products.

Of course, devices may support any number of audio and video codecs and negotiate the use of those codecs. The requirements here are the minimal set required to ensure a basic level of interoperability.

Deployment Options

There are several possible deployment options one may consider in order to interconnect with the H.323 Global Network. They are:

Individual hardware or software product(s) registered with an HGN network provider (including h323.net)
A Gatekeeper behind a NAT/FW
A Gatekeeper in the DMZ
A Gatekeeper on the public Internet (like h323.net, but owned privately)
One Gatekeeper behind a NAT/FW device and another in the public Internet or DMZ

We will explore each of these deployment options and provide guidance on configuration requirements for each.

Option 1: Individual Hardware or Software Device(s)

To connect a single or multiple separate hardware or software devices to the H.323 Global Network, the device(s) must be registered with a service that provides Gatekeeper functionality, such as h323.net. Each service may have its own set of requirements, and h323.net has its own terminal connectivity requirements. Please refer to the requirements specified by your interconnection provider.

This model may also be employed by an enterprise that wishes to locate a Gatekeeper in the public Internet (or in the DMZ with a public address). It is the most scalable of all deployment models discussed in this configuration guide, since each terminal is responsible for NAT/FW traversal.

Option 2: Gatekeeper in the DMZ

In this configuration, the Gatekeeper is responsible for providing the required NAT/FW traversal functionality. It should also support H.245 tunneling on behalf of the endpoints. This means that the endpoints would not need to provide that functionality directly.

Having said that, the internal network must have pinholes open through the firewall so that the terminals can communicate effortlessly with the DMZ Gatekeeper. If the internal firewall also performs network address translation, then this topology would not work without a Client Proxy as defined in H.460.18 and H.460.19. (Refer below for a diagram of such a deployment.)

If opening pinholes through the internal firewall is not possible, the other solution is to ensure that each of the terminals support H.460.23 and H.460.24. Having this support would also address and issues with NAT that might arise.

Option 3: Gatekeeper in Behind the NAT/FW (Scenario 1)

In this configuration, the Gatekeeper is located behind the enterprise or corporate firewall. In order to gain access to the outside world, the firewall must proxy all media and signaling on behalf of the terminals. It must also support H.460.23 and H.460.24 NAT/FW traversal standards, which is a general requirement for the HGN.

It is assumed that the Gatekeeper is accessible from the public Internet. This means that the firewall must have pinholes open that allow traffic to flow directly to the Gatekeeper, including the RAS and call signaling ports.

Option 4: Gatekeeper in Behind the NAT/FW (Scenario 2)

This configuration is similar to the previous option and has similar requirements.

The difference is that explicit pinholes are not required to be opened on the firewall. The reason is that the internal Gatekeeper registers with a Gatekeeper in the Internet, much like an endpoint would. Admittedly, it is unusual for a Gatekeeper to register with another Gatekeeper, but the H.323 standard does not preclude it, GnuGk supports it, and it enables more deployment possibilities.

Option 5: Gatekeeper in the DMZ with Client Proxy on the Intranet

This model is similar to the other model where the Gatekeeper is situated in the DMZ. The difference is that a Client Proxy (as defined in H.460.18 and H.460.19) is situated inside in the Intranet in order to facilitate traversal of media for devices that do not support any of the H.323 standards for NAT/FW traversal.

Media must be routed through the Gatekeeper in order for this model to work. Further, the Gatekeeper must support H.460.23 and H.460.24 to ensure that media can properly traverse the DMZ firewall.

Option 6: Public Gatekeeper with Client Proxy on the Intranet

This is a model that might be supported by the enterprise with its own cloud-based Gatekeeper or by a service provider that provides the Gatekeeper functionality and only requires a Client Proxy inside the enterprise.

This model does not require any specific functionality for the H.323 devices inside the enterprise, requiring only the installation of the Client Proxy. The Gatekeeper would be required to proxy media transmitted from the Client Proxy.

There must be a means of allowing the Gatekeeper to communicate directly with the Client Proxy. This will require ports opened through the NAT/FW device to facilitate that communication.

Configuring DNS

When using any of the deployment options above where an entity uses its own domain name to allow for inter-domain communication, one must insert entries into DNS. We will use the domain example.com to illustrate what those DNS entries should look like.

gk                      IN      A       192.168.15.15
_h323ls._udp            IN      SRV     0 0 1719 gk.example.com.

As explained in H.323 Annex O, users may be addressed with identifiers like user@example.com. When a call is initiated for a user using such an identifier, the Gatekeeper will perform a DNS query to determine how to route the call. The H.323 Global Network utilizes the _h323ls SRV records for this purpose. This SRV record will point to the Gatekeeper(s) that manage the target domain. The originating Gatekeeper will then send an LRQ to the discovered Gatekeeper and receive an LCF. This then allows the terminal to place a call to the target location.

All addresses exchanged via RAS must be public Internet addresses. If you have a configuration where the Gatekeeper is behind a NAT device, you must configure the Gatekeeper to use a public address when responding to LRQ messages. The GnuGK provides this support.

NAT/FW Requirements

Not all NAT/FW devices are the same, though most NAT/FW devices are supported by the H.323 Global Network. The one class of NAT/FW devices not supported are called "symmetric NAT" devices. (For a description of the various types of NAT devices, refer to the Tecnical Paper Firewall and NAT Traversal Problems in H.323 Systems.) If your NAT/FW device is a symmetric NAT, you must situate a Gatekeeper in the public Internet and open pinholes to that Gatekeeper.

All other NAT/FW device types are supported by the H.323 Global Network.

The key to HGN working properly is that devices that face the Internet support H.460.23 and H.460.24, as those two standards allow for NAT/FW traversal. Either that, or the devices must be literally on the public Internet. The public-facing device might be a Gatekeeper, but for scalability reasons, it is preferred that terminal devices support H.460.23 and H.460.24 natively. Otherwise, all media must transit through the Gatekeeper. That might be acceptable for any enterprise that has centralized Internet access, but it would potentially require deployment of more Gateekeper devices to handle media flows.

Use of STUN

H.460.23 and H.460.24 require the use of Classic STUN, which is a protocol used to determine the type of NAT/FW device sits between the terminal (or Gatekeeper front-ending the terminal) and the Internet. Any public STUN server may be used and any HGN service provider should provide a STUN server for use by its customers.

HGN Dial Plan

The preferred means of contacting users on the H.323 Global Network is to use H.323 URLs with identifiers in the form of user@example.com (also written as h323:user@example.com). This allows each network administrator to manage users in much the same way as email addresses. It also makes it easier for people to remember the contact addresses of associates.

As much as we really want to move away from using phone numbers, they will be with us for some time and we must have a way to deal with those.

The HGN has a private nunbering plan administered by h323.net with numbers that start with +87840. The network also utilizes ENUM services offered by NRENum.net, which allows network managers to register existing E.164 addresses for use on the HGN. Lastly, Internet2 has a global dialing scheme called GDS which is accessable from any HGN-compliant network by dialing 00 followed by the GDS number.