H.323 Global Network Configuration Guide
Contents
- Introduction
- Interconnection Requirements
- Deployment Models
- Model 1: Individual Hardware or Software Device(s)
- Model 2: Gatekeeper in the DMZ
- Model 3: Gatekeeper in Behind the NAT/FW (Scenario 1)
- Model 4: Gatekeeper in Behind the NAT/FW (Scenario 2)
- Model 5: Gatekeeper in the DMZ with Client Proxy on the Intranet
- Model 6: Public Gatekeeper with Client Proxy on the Intranet
- Configuring DNS
- NAT/FW Requirements
- Use of STUN
- H.323 Global Network Dial Plan
- Step-by-Step Sample Configuration
Introduction
This guide is intended for network administrators, Value-Added Resellers (VARs), equipment suppliers, systems integrators, etc. who wish to enable video communication services to an enterprise or small/medium business by interconnecting with the H.323 Global Network (HGN).
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 to properly configure DNS settings, Gatekeepers, and ensure that a compatible NAT/FW device is employed. This guide provides administrators with the necessary information to successfully interconnect with the HGN.
Note that this guide is updated from time to time 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 (including all H.460.23/24 Annexes)
- H.245 tunneling
- G.711 for voice
- H.263 for video
- H.323 Annex O
- ENUM (including DNAME DNS records; rooted at enum.h323.net)
Other audio and video codecs may be supported, but the above set is specified to ensure a minimum level of interoperability.
Lastly, all Gatekeepers, SBCs, or other devices that perform address resolution should process H.323 URLs and must support ENUM queries. H.323 URL resolution must follow H.323 Annex O and must also query the h323.net domain for RDS records. To resolve phone numbers, Gatekeeper and the like must query whatever local configuration exists, then perform an ENUM query with the root enum.h323.net.
It is required that devices support H.264 for video. Given the availability of freely available H.264 libraries (namely, the Open H.264 library with license royalties fully paid by Cisco), the cost barrier to offering excellent video software is eliminated.
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 Models
There are several possible deployment options one may consider to interconnect with the H.323 Global Network. They are:
- Individual hardware or software product(s) registered with an HGN network service provider
- A Gatekeeper behind a NAT/FW
- A Gatekeeper in the DMZ
- A Gatekeeper on the public Internet
- 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.
Model 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. Each service may have its own set of requirements. Please refer to the requirements specified by your service 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.
Model 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 supports H.460.23 and H.460.24. Having this support would also address any issues with NAT that might arise.
Model 3: Gatekeeper in Behind the NAT/FW (Scenario 1)
In this configuration, the Gatekeeper is located behind the enterprise or corporate firewall. 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.
Model 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 on 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.
Model 5: Gatekeeper in the DMZ with Client Proxy on the Intranet
This model is like 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 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 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.
Model 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
Self-Managed by Domain Owners
When using any of the deployment options above where a domain owner 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.
Hosted/Managed DNS Entries
For domain owners who are unable to configure DNS records for their domain, DNS entries are entered into the Resolver Discovery Systems (RDS) for the H.323 Global Network. As the name implies, the RDS concept was borrowed from RFC 2915 and applied to H.323. The RDS for the H.323 Global Network is rooted at rds.h323.net.
Systems that attempt to resolve an H.323 URL should first query the target domain for DNS records as described in H.323 Annex O (shown in the previous section). One should always assume that the domain owner is operating and managing his own H.323 services connected to the H.323 Global Network before looking for RDS records as described in this section.
Failing to find SRV records per H.323 Annex O, the requesting system should determine the address of the RDS service for the target domain. This is done by locating the matching NAPTR record in rds.h323.net for the target domain. The H.323 Global Network presently defines this NAPTR record:
@ IN NAPTR 100 10 "" "" "!^h323:(.+)@([a-z0-9\\-\\.]*)\;*(.*)$!\\2.rds.h323.net!i" .
In the spirit of RFC 2915, this NAPTR record says that any URL of the form h323:user@example.com should be further resolved by querying for NAPTR records located at example.com.rds.h323.net. (Note the double backslashes are in the DNS record since \ is an escape character and we need a literal \ in the regular expression. So, the regular expression that would be acted upon is "^h323:(.+)@([a-z0-9\-\.]*);*(.*)$" which then maps to "!\2.rds.h323.net!i".)
The above step merely tells us where the RDS service is located, but since it is possible that we might have multiple locations based on the domain name, it is important that clients identify the RDS location for the target domain and not assume rds.h323.net. In the future, there may be additional NAPTR records defined, and it is incumbent on the requesting entity to evaluate the regular expressions to determine which record to utilize.
Continuing with the above example, the requesting entity would then query for NAPTR records at example.com.rds.h323.net. In the DNS, one would find this entry under rds.h323.net:
example.com IN NAPTR 50 50 "s" "H323+D2U" "" _h323ls._udp.example.com.rds.h323.net.
This example.com.rds.h323.net NAPTR record identifies the SRV record location for the target domain. It follows the approach defined in RFC 3263 for locating SIP servers and tells us that to resolve the H.323 URL for user@example.com, one uses the SRV record found at _h323ls._udp.example.com.rds.h323.net. The "s" indicates SRV records as per RFC 2915. For H.323 systems, the service name "H323+D2U" refers to the UDP-based location service for the target domain (i.e., _h323ls as defined in H.323 Annex O).
The requesting entity then queries for the SRV record _h323ls._udp.example.com.rds.h323.net and follows the normal H.323 Annex O procedures to resolve the destination address h323:user@example.com.
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 Technical 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 (see the paper The H.323 NAT/FW Traversal Solution), 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 Gatekeeper 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.
H.323 Global Network 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 numbering plan with numbers that start with +87840. Packetizer (who hosts h323.net) can also register your company's existing numbers so they are a part of the HGN or delegate the management of those numbers to your organization. The network also interfaces with ENUM services offered by NRENum.net, which allows resolving addresses used in academia. Lastly, Internet2 has a global dialing scheme called GDS which is accessible from any HGN-compliant network by dialing 00 followed by the GDS number.
For those who wish to allocate numbers for their own use and manage those allocations, you can be provided a DNAME record to allow for management of any number of branches under +87840 allocated to you, similar to this entry rooted at enum.h323.net:
9.0.8.6.1.1.0.4.8.7.8 IN DNAME 9.0.8.6.1.1.0.4.8.7.8.enum.packetizer.com
*.9.0.8.6.1.1.0.4.8.7.8.enum.packetizer.com. IN NAPTR 100 10 "u" "E2U+h323" "!^(.*)$!h323:\\1@packetizer.com!" .
This would mean that users looking to reach all numbers starting with +87840116809 would consult the ENUM server at packetizer.com to complete the resolution process. On that domain, there would be an entry or entries like the NAPTR record shown above. Essentially, your organization would be able to manage a portion of the enum.h323.net subdomain to allocate numbers as desired.
Step-By-Step Sample Configuration
If you wish to set up GnuGk to provide H.323 connectivity services for your domain, here is a step-by-step guide you can follow, along with links to get some help from others who have configured their own servers.