Cisco gatekeepers group gateways into logical zones and perform call routing between them. Cisco gatekeepers handle call routing among gateways in the H.323 network and provide centralized dial plan administration. Without a Cisco gatekeeper, Voice over IP (VoIP) dial peers would need to be configured in every originating gateway for each possible termination gateway within the network. These would need to point to the specific IP address (or DNS name) for each terminating gateway. With a Cisco gatekeeper, gateways query the gatekeeper when trying to establish VoIP calls with a remote VoIP gateway.
For example, when a call request is made, the gateway determines whether to send it to a connected trunk (public switched telephone network [PSTN] or PBX) or to an IP destination based on the configured dial plan. In the case of an IP destination, the gateway queries the Cisco gatekeeper to select the best gateway.
ARQ and LRQ are the two RAS messages that initiate call routing. Gatekeepers receive ARQ messages from a gateway registered to a local zone either as a result of an outbound call initiation from the gateway or to request permission to accept an incoming call.
LRQ messages are passed between different gatekeepers and are used to route calls from a local to a remote zone (interzone routing).
A zone prefix is the part of a called number that identifies the destination zone (local or remote) for the call. Zone prefixes can be based on area codes and local exchanges, or any characteristic of the called number prefix that makes it unique to the call routing domain. If the network is supporting extension dialing between locations, the zone prefix might be the first number of the extension or a location code used to identify a remote site. Whatever prefix is selected must be unique so that the gatekeeper can select the proper destination zone for the call.
In Example 16-1, calls beginning with 212 are routed to the NY local zone, and calls beginning with 208 are routed to the BO local zone.
gatekeeper zone local NY cisco.com 10.1.5.1 1719 zone local BO cisco.com zone prefix NY 212……. zone prefix BO 208…….
You can configure zone prefixes manually, as shown in the example. Cisco IOS Versions 12.1T and later support an H.323 Version 2 enhancement that allows automatic creation of zone prefixes for devices with assigned E.164 addresses that are attached to the gateway, such as phones connected to Foreign Exchange Station (FXS) ports. Cisco IOS Versions 12.2.15T and later support an H.323 Version 4 feature that allows gateways to dynamically register prefixes that are assigned to POTS dial peers.
Multiple prefixes can exist for a single local zone, and a gateway belonging to multiple zone prefixes might register to the gatekeeper.
Prefixes can have overlapping number ranges. If prefixes overlap, the prefix that has the longest match is used. For example, if you have defined a prefix for the NY gateway as "212" and one for the Boise gateway as "2..", the prefixes will overlap. In this case, both prefixes begin with a "2," and numbers beginning with "212" could match either prefix. However, the longest match is to the NY prefix of "212," and it will always be selected. Conversely, a "212" number will never match the "2" prefix, even if the NY gateway is not registered to the gatekeeper. In this case, the "212" prefix will still be matched, but the address of the gateway will be unknown, so an ARJ will be sent. An exception to this is if the prefixes are dynamically learned from the gateways. In this case, if the NY gateway is unregistered, the "212" prefix will be deleted, and the "2.." prefix will be matched.
It is important to understand how prefix matching is done so that you can properly design a gatekeeper-controlled dial plan.
A technology prefix is an optional H.323 feature that the Cisco gatekeeper uses to group gateways by type (such as voice or video) or class or to define a pool of gateways.
When you are routing a call, you use the technology prefix when no registered E.164 address matches the called number.
To use technology prefixes, you must do two things:
This identifies the technology (type, class, or pool) that the gatekeeper associates with this particular gateway when performing call routing.
The technology prefix is stripped from the called number when the gateway attempts to match a zone prefix. However, the full number with the technology prefix is delivered to the destination gateway. Be sure that POTS dial-peers are updated to handle this properly.
You can also configure a default technology prefix in the gatekeeper. Registered gateways with the matching technology prefix are used as default for routing call addresses that are unresolved. Some H.323 endpoints do not support coding a technology prefix. The default technology that is defined on the gatekeeper is also used for those devices.
You can also configure hop-offs on the gatekeeper based on technology prefix. A hop-off is used to override the zone prefix and force the call to be routed to the specified hop-off zone regardless of the called number zone prefix.
Technology prefixes are most often used in multimedia H.323 networks to identify the type of call as either video or voice. They are also used in large networks where multiple gateways are pooled to provide greater capacity and redundancy.
Gatekeeper Call Routing Process
Figure 16-6 illustrates the overall process that the Cisco gatekeeper uses to try to route a call. The Cisco multiservice IP-to-IP gateway (IPIPGW) feature introduces gatekeeper via-zones. The sections of the diagram that are labeled "Via-Zone Processing" refer to a separate decision tree process that the via-zone-enabled gatekeepers use in an IPIPGW environment. This concept is discussed in Chapter 18, "Cisco Multiservice IP-to-IP Gateway."
Figure 16-6. Gatekeeper Call Routing Decision Tree
Part I: Voice Gateways and Gatekeepers
Gateways and Gatekeepers
Part II: Gateways
Media Gateway Control Protocol
Session Initiation Protocol
Connecting to the PSTN
Connecting to PBXs
Connecting to an IP WAN
Influencing Path Selection
Configuring Class of Restrictions
SRST and MGCP Gateway Fallback
Using Tcl Scripts and VoiceXML
Part III: Gatekeepers
Part IV: IP-to-IP Gateways
Cisco Multiservice IP-to-IP Gateway
Appendix A. Answers to Chapter-Ending Review Questions