Cisco gatekeepers are used to group gateways into logical zones and perform call routing between them. Gateways are responsible for edge routing decisions between the Public Switched Telephone Network (PSTN) and the H.323 network. Cisco gatekeepers handle the core call routing among devices in the H.323 network and provide centralized dial plan administration. Without a Cisco gatekeeper, explicit IP addresses for each terminating gateway would have to be configured at the originating gateway and matched to a Voice over IP (VoIP) dial-peer. With a Cisco gatekeeper, gateways query the gatekeeper when trying to establish VoIP calls with remote VoIP gateways.

For example, when presented with a call, the gateway determines whether to send it to the telephony leg or to the IP leg according to its dial plan. In the case of the IP leg, the gateway queries the Cisco gatekeeper to select the best endpoint. Then, the Cisco gatekeeper determines if the called endpoint is a device within its local zone or it is located at a remote zone controlled by a remote Cisco gatekeeper.

The information in this document is based on these software and hardware versions:

Cisco 2500, 2600, 3600, 3700, 7200, and MC3810 Series Routers

This document is not specific to any version of Cisco IOS®. However, the configurations in this document were tested on Cisco IOS Software Release 12.2(19). Refer to the Software Advisor (registered customers only) to confirm the Cisco IOS feature set needed to support the H.323 Gatekeeper functionality.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

ARQ—Local zone messages that are sent by H.323 endpoints (usually gateways) to the Cisco gatekeeper. Gatekeepers receive ARQs from an endpoint if:

A local zone endpoint initiates a call. OR

A local zone endpoint request permission to admit an incoming call.

Gatekeepers reply to ARQ messages with an Admission Confirm (ACF) or an Admission Reject (ARJ) message. If the Cisco gatekeeper is configured to admit the call, it replies with an ACF message (which includes information such as destination gateway IP address). If not, it replies with an ARJ message.

LRQ—These messages are exchanged between gatekeepers and are used for inter-zone (remote zone) calls. For example, gatekeeper A receives an ARQ from a local zone gateway requesting call admission for a remote zone device. Gatekeeper A then sends an LRQ message to gatekeeper B. Gatekeeper B replies to the LRQ message with either a Location Confirm (LCF) or Location Reject (LRJ) message, which depends on whether it is configured to admit or reject the inter-zone call request and whether the requested resource is registered.

In order to understand the Cisco gatekeeper call routing decision process, it is essential to understand zone and technology prefixes. In general (with a few exceptions), the zone prefix determines the routing to a zone, whereas the technology prefix determines the gateway in that zone.

A zone prefix is the part of the called number that identifies the zone to which a call hops off. Zone prefixes are usually used to associate an area code to a configured zone.

The Cisco gatekeeper determines if a call is routed to a remote zone or handled locally. For example, according to this configuration excerpt, gatekeeper (GK) A forwards 214....... calls to GK-B. Calls to area code (512) are handled locally.

gatekeeper
zone local GK-A abc.com
zone remote GK-B abc.com 172.22.2.3 1719
!--- The IP address configured above should be the RAS !--- address of the remote gatekeeper. !--- and should be reachable from the local gateway. !--- In order to find out the RAS address on the remote gatekeeper, !--- issue the show gatekeeper zone status command !--- on the remote gateway.
zone prefix GK-B 214.......
zone prefix GK-A 512.......

A technology prefix is an optional H.323 standard-based feature, supported by Cisco gateways and gatekeepers, that enables more flexibility in call routing within an H.323 VoIP network. The Cisco gatekeeper uses technology prefixes to group endpoints of the same type together. Technology prefixes can also be used to identify a type, class, or pool of gateways.

Cisco gatekeepers use technology prefixes to route calls when there is no E.164 addresses registered (by a gateway) that matches the called number. In fact, this is a common scenario because most Cisco IOS gateways only register their H.323 ID (unless they have Foreign Exchange Station (FXS) ports configured). Without E.164 addresses registered, the Cisco gatekeeper relies on two options to make the call routing decision:

With the Technology Prefix Matches option, the Cisco gatekeeper uses the technology prefix appended in the called number to select the destination gateway or zone.

With the Default Technology Prefixes option, the Cisco gatekeeper assigns default gateway(s) for routing unresolved call addresses. This assignment is based on the gateways' registered technology prefix.

This table summarizes available configuration options:

On the Gateway

VoIP Interface

This command registers the Cisco gateway with the defined technology prefix. The technology prefix registration information is sent to the Cisco gatekeeper in the RAS Registration Request (RRQ) message. For example:

GWY-B1(config)#interface ethernet 0/0
GWY-B1(config-if)#h323-gateway voip tech-prefix ?
WORD: A technology prefix that the interface will register
with the Gatekeeper.

VoIP Dial-peer

This command prepends a technology prefix to the called number matched by the dial-peer. It is not used for registration, but for call setup with the Cisco gatekeeper. For example, called number 5551010 becomes 1#5551010.

Note: The modified called number is also sent to the terminating gateway in the call setup. Ensure the terminating gateway plain old telephone service (POTS) dial-peers are updated to complete the call.

On the Gatekeeper

Gatekeeper Default Technology Prefix

This command sets registered gateways with the specified technology prefix as default for routing call addresses that are unresolved. For example, if most gateways in your zone route the same type of calls and they are registered with technology prefix 1#, you can configure the Cisco gatekeeper to use 1# as the default technology prefix. Therefore, it is no longer necessary for originating gateways to prepend the called number with 1#. Called numbers without a valid technology prefix are routed to one of the gateways registered with 1#.

Note: If there is more than one default gateway, you can affect the gateway priority usage with the zone prefix <gk_id><e.164_pattern> gw-priority <0-10> command.

Gatekeeper Hop-Off Zone

Hop-off configurations are used to override the zone prefix selection and force the call to be hopped-offed to a specified zone, regardless of the called number zone prefix. For example, with this configuration, all calls with technology prefix 2# will be forwarded to the GK-A zone.

GK-B(config)#gatekeeper
GK-B(config-gk)#gw-type-prefix 2# hopoff GK-A

Gatekeeper Static Gateway Technology Prefix Registration

Used to statically register a technology prefix for a gateway. It accomplishes the same results on the gatekeeper as the gateway VoIP interface configuration achieves on the gateway . It is recommended to configure this on the gateways if you have a large number of gateways. Generally, it is easier to configure each gateway with a technology prefix than to configure the gatekeeper with all technology prefixes for each gateway.

The gatekeeper call routing has changed in Cisco IOS Software Release 12.4 and later. H.323-ID and email-ID based matching is performed before processing the destination E.164 numbers (DNIS). If any endpoint is found to have registered the specified H.323-ID/email-ID, then the ACF is sent. This diagram explains the new alias-based call routing process:

The Voice Infrastructure and Application (VIA) functions are software enhancements to the existing Cisco gatekeeper image. With this enhancement, the Cisco gatekeeper can recognize two call legs on the same platform (IP-to-IP gateway) and also load-balance traffic across multiple IP-to-IP gateways, which are included (both gateways and gatekeepers) in a predefined VIA zone. These gatekeepers sit at the edge of the Internet Telephony Service Provider (ITSP) network and are like a VoIP transfer point, or transit zone, where VoIP traffic is channeled through on the way to the remote zone destination. IP-to-IP gateways in the VIA zone terminate incoming calls and reoriginate them toward their final destinations. Refer to Remote to Local Network with the Cisco Multiservice IP-to-IP Gateway Feature for more information on VIA zone.

Note: If the specified invia or outvia zone is not found in the configs (i.e. it is not defined as either a local or remote zone), then an ARJ message is sent.

In order to select an IP-IP GW registered to the selected viazone this algorithm is used:

If a tech-prefix is found (in alias-based matching), look through the list of gateways in the specified viazone that have registered this tech-prefix.

If no tech-prefix is found, look through the entire list of gateways registered to the specified viazone.

Select the first IP-IP GW found in step 1 or 2 that has resources available.

If all the IP-IP GWs in the list are out of resources, select the first IP-IP GW that is found (even though it might be out of resources).

In the examples provided in this section, the two gateways register with the Cisco gatekeeper with their respective H.323 IDs. In addition, gateway (GWY) A2 registers with an E.164 address. This diagram is used for all the examples in this section:

The three scenarios in this section explain the step-by-step decision process the gatekeeper uses to route calls based on the ARQ messages.

GK-A—Added the arq reject-unknown-prefix command. This enforces GK-A to accept only ARQ calls for zone prefixes it manages. In scenario 1, this was not configured. Therefore, the target zone was set to the local zone as default.

GWY-A2—Added the tech-prefix 1# command under the VoIP dial-peer configuration. This way, GWY-A2 prepends the digits 1# to outgoing VoIP calls. GK-A identifies the 1# pattern to select GWY-A1 as the destination gateway.

Note: Instead of configuring GW-A1 with the h323-gateway voip tech-prefix 1# command, it can be accomplished the same way by manually configuring this information in the GK-A with the command.

GK-A(config-gk)#gw-type-prefix 1#* gw ipaddr 172.22.1.1

Call Action: User A2 dials 512-555-1212 to call user A1.

GK-A receives ARQ from GWY-A2.

Does the technology prefix match? Yes

Note: After the technology prefix match, the gatekeeper strips it to analyze the zone prefix. This strip is only performed by the gatekeeper analysis. The originating gateway still appends it in the call setup to the terminating gateway.

Does the zone prefix match? Yes. Set the target-zone to equal the local zone.

Note: This is an alternative configuration that can be more intuitive:

Issue the h323-gateway voip tech-prefix 512 command in order to configure GWY-A1 to register with technology prefix 512.

This way, GWY-A2 does not have to pass the prefix in the VoIP dial-peer call leg because the destination-pattern already includes 512. Therefore, take out the tech-prefix 1# command in the GWY-A2 configuration and also remove 1# from the destination-pattern under the pots dial peer on GWY-A1.

In this scenario, GWY-A1 registers with technology prefix 1# and GK-A is configured to route calls without a technology prefix match to the default technology prefix gateways. Therefore, GWY-A2 does not need to be configured to pass the destination technology prefix.

In this scenario, GWY-A1 registers to GK-A with technology prefix 1# and GWY-B1 registers to GK-B with technology prefix 2#. GWY-A1 adds technology prefix 2# to the called number string when making calls to (214) and GWY-B1 adds technology prefix 1# to the called number string when making calls to (512).