Request For Comment

A Global Alphanumeric Naming Scheme for H.323

Draft July 12, 1999

Tyler Miller Johnson, University of North Carolina at Chapel Hill

Robert Dixon, Ohio State University

Mary Fran Yafchak, NYSERNET

Summary

This RFC describes a naming scheme, sometimes referred to as a dialing plan, for h.323 terminal end stations on the Internet, Internet2 and related networks. It includes provisions for both numeric and alphanumeric naming. A key feature of this dialing plan is that the address of the destination zone's gatekeeper is embedded in each name, thus providing a means for direct resolution of all names and eliminating the scalability problems of 'advertised' or statically registered zones as described in Annex G of the h.323 standard. Another key provision is that this naming scheme is based upon existing infrastructures and does not require the formation of a body to administer names. Thus, all users on the network can immediately begin to implement the plan.

General Support for Naming Schemes

Gatekeepers identify terminal end stations within their zones by means of a unique name. Gatekeepers should support both alphanumeric and numeric name registration schemes simultaneously. Within each scheme, multiple names should be supported for each registered terminal end station. Alphanumeric naming should be the commonly used convention for IP-based communications, since most computers can easily dial strings, such as John_Doe@foo.edu. Numeric dialing, i.e. telephone numbers, should be reserved for systems that seek extensive bridging with public switched networks, including voice and h.320 applications.

Alphanumeric Naming Scheme

Terminal end stations should be named according to the convention user@gatekeepername.domain. Domain is any valid DNS domain name under the administrative control of the network hosting the zone. Gatekeepername is the DNS name of the gatekeeper. Thus, gatekeepername.domain identifies a unique gatekeeper, i.e. zone, on the network and is referred to as an alphanumeric zone identifier. User is a unique terminal end station within the zone.

Taken together, the full user@gatekeepername.domain name is referred to as a user's multimedia conferencing alias, or MCA, and is stored in the h.323 email alias field.

This scheme guarantees that each administrative domain on the network can implement unique zone and terminal end station names. It has the advantage of being built upon the existing DNS naming scheme, and thus does not require that any organization be charged with managing zone and terminal names on the network. Individual domains can immediately begin implementing zones and adding terminals to the network.

Since not all networks implement DNS, terminals may also secondarily be registered as user@IP where user is defined as above and IP is the IP address of the gatekeeper that is resolved from gatekeepername.domain above.

Services should follow the same naming convention. Thus, a 384kb/s multipoint call might be named mcu384@gatekeepername.gk1.unc.edu. It would similarly be registered as mcu384@152.2.21.1 and mcu384 for in-zone calls.

Example: Assume a gatekeeper with an IP address of 152.2.21.1 and a DNS name of gk1.unc.edu and a user John Doe. John Doe should be registered in the gatekeeper as John_Doe@gk1.unc.edu and John_Doe@152.2.21.1 He may also be registered as John_Doe for in-zone calling purposes.

Numeric Naming Scheme

Full numeric names should consist of a string of 12 digits representing a numeric zone identifier, followed by the * (star) delimiter on the numeric keypad, followed by a variable length string of digits representing an extension. The numeric zone identifier must be the IP address, including leading zeros and excluding . (dot) characters, of the zone's gatekeeper. This numeric zone identifier will uniquely identify that zone on the network. The extension will uniquely identify specific terminal end stations within the zone. Taken together, the full numeric zone identifier * extension name is referred to as a user's multimedia conferencing number, or MCN, and is stored in the h.323 extension field.

When dialing into an h.323 zone via a gateway from the PSTN, the user should dial the telephone number of the gateway followed by the MCN of the desired party. In the case of dialing a party in the same zone as the gateway itself, the MCN can be truncated to just the extension.

When dialing out of an h.323 zone via a gateway into the PSTN, the user should dial the gateway service number, followed by the desired PSTN telephone number.

Services within the zone should be dialed as prefixes and also be delimited by the * (star) character. This includes both exit zone prefixes, as well as prefixes enumerating multipoint calls, gateways, etc. Thus, a 384Kb/s multipoint call could be defined as 234*, a gateway call defined as 567*, etc. While services may be defined by any number of digits, 1* should always be used by convention as the exit zone prefix, to conform to user expectations about dialing 1 for long distance calls.

Example: Assume a numeric zone identifier (gatekeeper) with an IP address of 152.2.21.1 and a terminal end station with an extension of 354. An in-zone call to this extension would be dialed as 354. An out of zone call to this extension would be dialed as 1* 152002021001* 354.

Gatekeeper Resolution

With the above alphanumeric naming scheme in place, gatekeepers should identify called zones by simply parsing and resolving the gatekeepername.domain portion of the address and signaling that zone directly. This means that gatekeepers need not, and should not, use a broadcast/multicast mechanism or static table to identify out-of-zone destinations. Since broadcast schemes and static tables do not scale globally, direct gatekeeper IP address resolution is the preferred method of call destination resolution. Calls originating with a destination lacking a zone identifier (e.g. John_Doe) should be interpreted as in-zone calls. If the destination is not found locally, an error should be returned to the call originator.

Gatekeeper resolution of numeric names should likewise utilize the numeric zone identifier embedded within the name to signal that remote gatekeeper directly. As is the case with alphanumeric dialing, gatekeepers need not, and should not, use a broadcast/multicast mechanism or static table to identify out-of-zone destinations