You can configure interzone routing using E.164 addresses.
Two types of address destinations are used in H.323 calls. You can specify a destination using either an H.323-ID address (a character string) or an E.164 address (a string that contains telephone keypad characters). The way in which interzone calls are routed depends on the type of address being used.
When using H.323-ID addresses, interzone routing is handled through the use of domain names. For example, to resolve the domain name firstname.lastname@example.org, the source endpoint gatekeeper finds the gatekeeper for cisco.com and sends it the location request for the target address email@example.com. The destination gatekeeper looks in its registration database, sees bob registered, and returns the appropriate IP address to get to bob.
When using E.164 addresses, call routing is handled through zone prefixes and gateway-type prefixes, also referred to as technology prefixes. The zone prefixes, which are typically area codes, serve the same purpose as domain names in H.323-ID address routing. Unlike domain names, however, more than one zone prefix can be assigned to one gatekeeper, but the same prefix cannot be shared by more than one gatekeeper.
Use the zone prefix command to define gatekeeper responsibilities for area codes. The command can also be used to tell the gatekeeper which prefixes are in its own zones and which remote gatekeepers are responsible for other prefixes.
Area codes are used as an example in this section, but a zone prefix need not be an area code. It can be a country code, an area code plus local exchange (NPA-NXX), or any other logical hierarchical partition.
The following sample command shows how to configure a gatekeeper with the knowledge that zone prefix 212....... (that is, any address beginning with area code 212 and followed by seven arbitrary digits) is handled by gatekeeper gk-ny:
my-gatekeeper(config-gk)# zone prefix gk-ny 212.......
When my-gatekeeper is asked to admit a call to destination address 2125551111, it knows to send the location request to gk-ny.
However, once the query gets to gk-ny, gk-ny still needs to resolve the address so that the call can be sent to its final destination. There could be an H.323 endpoint that has registered with gk-ny with that E.164 address, in which case gk-ny would return the IP address for that endpoint. However, it is more likely that the E.164 address belongs to a non-H.323 device, such as a telephone or an H.320 terminal.
Because non-H.323 devices do not register with gatekeepers, gk-ny has no knowledge of which device the address belongs to or which type of device it is, so the gatekeeper cannot decide which gateway should be used for the hop off to the non-H.323 device. (The term hop off refers to the point at which the call leaves the H.323 network and is destined for a non-H.323 device.)
The number of zone prefixes defined for a directory gatekeeper that is dedicated to forwarding LRQs, and not for handling local registrations and calls, should not exceed 10,000; 4 MB of memory must be dedicated to describing zones and zone prefixes to support this maximum number of zone prefixes. The number of zone prefixes defined for a gatekeeper that handles local registrations and calls should not exceed 2000.
To enable the gatekeeper to select the appropriate hop-off gateway, use the gw-type-prefix command to configure technology or gateway-type prefixes. Select technology prefixes to denote different types or classes of gateways. The gateways are then configured to register with their gatekeepers using these technology prefixes.
For example, voice gateways might register with technology prefix 1#, and H.320 gateways might register with technology prefix 2#. If there are several gateways of the same type, configure them to register with the same prefix type. By having them register with the same prefix type, the gatekeeper treats the gateways as a pool out of which a random selection is made whenever a call for that prefix type arrives. If a gateway can serve more than one type of hop-off technology, it can register more than one prefix type with the gatekeeper.
Callers must identify the type of gateway by prepending the appropriate technology prefix for that gateway type to the destination address. For example, callers might request 1#2125551111 if they know that address 2125551111 is for a telephone and that the technology prefix for voice gateways is 1#. The voice gateway is configured with a dial peer (using the dial-peer command) so that when the gateway receives the call for 1#2125551111, it strips off the technology prefix 1# and bridges the next leg of the call to the telephone at 2125551111.
In cases in which the call scenario is as shown in the figure below, voice-gw1 can be configured to prepend the voice technology prefix 1# so that the use of technology prefixes is completely transparent to the caller.
Additionally, in using the gw-type-prefix command, a particular gateway-type prefix can be defined as the default gateway type to be used for addresses that cannot be resolved. It also forces a technology prefix to always hop off in a particular zone.
If the majority of calls hop off on a particular type of gateway, the gatekeeper can be configured to use that type of gateway as the default type so that callers no longer have to prepend a technology prefix on the address. For example, if voice gateways are mostly used in a network, and all voice gateways have been configured to register with technology prefix 1#, the gatekeeper can be configured to use 1# gateways as the default technology if the following command is entered:
Router(config-gk)# gw-type-prefix 1# default-technology
Now a caller no longer needs to prepend 1# to use a voice gateway. Any address that does not contain an explicit technology prefix is routed to one of the voice gateways that registered with 1#.
With this default technology definition, a caller could ask the gatekeeper for admission to 2125551111. If the local gatekeeper does not recognize the zone prefix as belonging to any remote zone, it routes the call to one of its local (1#) voice gateways so that the call hops off locally. However, if it knows that gk-ny handles the 212 area code, it can send a location request for 2125551111 to gk-ny. This requires that gk-ny also be configured with some default gateway type prefix and that its voice gateways be registered with that prefix type.
For ease of maintenance, the same prefix type should be used to denote the same gateway type in all zones under your administration.
Also, with the gw-type-prefix command, a hop off can be forced to a particular zone. When an endpoint or gateway makes a call-admission request to its gatekeeper, the gatekeeper determines the destination address by first looking for the technology prefix. When that is matched, the remaining string is compared against known zone prefixes. If the address is determined to be a remote zone, the entire address, including technology and zone prefixes, is sent to the remote gatekeeper in a location request. That remote gatekeeper then uses the technology prefix to decide on which of its gateways to hop off. In other words, the zone prefix (defined using the zone prefix command) determines the routing to a zone, and once there, the technology prefix (defined using the gw-type-prefix command) determines the gateway to be used in that zone. The zone prefix takes precedence over the technology prefix.
This behavior can be overridden by associating a forced hop-off zone with a particular technology prefix. Associating a forced hop-off zone with a particular technology prefix forces the call to the specified zone, regardless of what the zone prefix in the address is. As an example, you are in the 408 area code and want callers to the 212 area code in New York to use H.323-over-IP and hop off there because it saves on costs. However, the only H.320 gateway is in Denver. In this example, calls to H.320 endpoints must be forced to hop off in Denver, even if the destination H.320 endpoint is in the 212 area code. The forced hop-off zone can be either a local zone (that is, one that is managed by the local gatekeeper) or a remote zone.