Products & Services

Understanding Cisco IOS Gatekeeper Call Routing

Document ID: 24462

Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
ARQ and LRQ Messages
Important Configuration Concepts: Zone and Technology Prefixes
Zone Prefixes
Technology Prefixes
The Gatekeeper Call Routing Algorithm / Decision Process
Alias-Based Call Routing
Local Zone Call Examples
Scenario 1: No Technology Prefixes Configured
Scenario 2: Technology Prefixes Configured
Scenario 3: Default Technology Prefixes Configured
Remote Zone Call Examples
Scenario 1: Zone Gatekeepers Configured with Default Technology Prefixes
Scenario 2: Zone Gatekeepers Configured without Default Technology
Prefixes
Verification and Troubleshooting Commands
Cisco Support Community - Featured Conversations
Related Information

Introduction

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.

Prerequisites

Requirements

Cisco recommends that you have knowledge of Understanding H.323 Gatekeepers.

Components Used

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.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

ARQ and LRQ Messages

Admission Request (ARQ) and Location Request (LRQ) are the two H.225 Registration, Admission, Status (RAS) messages
that trigger a gatekeeper to initiate the call routing decision process.

 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.

Refer to Understanding H.323 Gatekeepers: Gatekeeper to Gateways Call Flow for more information.

Related H.225 RAS Messages

ARQ Admission Request LRQ Location Request
ACF Admission Confirm LCF Location Confirm
ARJ Admission Reject LRJ Location Reject

Important Configuration Concepts: Zone and Technology Prefixes

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.

Zone Prefixes

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.......

Technology Prefixes

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
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:
VoIP
Interface 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.
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.

VoIP GWY-B1(config)#dial-peer voice 2 voip

Dial-
peer
GWY-B1(config-dial-peer)#tech-prefix ?
WORD: A string.

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
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
Gatekeeper number with 1#. Called numbers without a valid technology prefix are routed to one of
Default the gateways registered with 1#.
Technology
Prefix GK-B(config)#gatekeeper
GK-B(config-gk)#gw-type-prefix 1# default-technology

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.
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.
Gatekeeper For example, with this configuration, all calls with technology prefix 2# will be forwarded
Hop-Off to the GK-A zone.
Zone
GK-B(config)#gatekeeper
GK-B(config-gk)#gw-type-prefix 2# hopoff GK-A
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
Gatekeeper
number of gateways. Generally, it is easier to configure each gateway with a
Static
technology prefix than to configure the gatekeeper with all technology prefixes for each
Gateway
gateway.
Technology
Prefix
Registration GK-B(config)#gatekeeper
GK-B(config-gk)#gw-type-prefix 1# gw ipaddr ?
A.B.C.D Gateway's call signaling IP address

The Gatekeeper Call Routing Algorithm / Decision Process

These diagrams display the gatekeeper call routing decision process after receiving ARQ and LRQ messages in Cisco IOS
Software Releases before 12.4:
Alias-Based Call Routing

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:

1. 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.

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

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

4. 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).

5. If no IP-IP GWs are found, return failure.

Local Zone Call Examples

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.

Note: Only relevant output is shown in these configuration captures.

Scenario 1: No Technology Prefixes Configured

GK-A
!
gatekeeper
zone local GK-A abc.com
no shutdown
!
GWY-A1 GWY-A2

!
interface Ethernet0/0
 ip address 172.22.1.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718

!--- The IP address configured here should

!
!--- be the RAS address of GK-A
interface FastEthernet0/0
!--- and should be reachable from the gateway.
ip address 172.22.1.2 255.255.255.0
!--- In order to find out the RAS address,
h323-gateway voip interface
!--- issue the
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
show gatekeeper zone status
!--- The IP address configured here
!--- command on GK-A.
!--- should be the RAS address of GK-A.
!--- and should be reachable from the gateway.
h323-gateway voip h323-id [email protected]
!--- In order to find out the RAS address,
!
!--- issue the
dial-peer voice 1 pots
show gatekeeper zone status
destination-pattern 512.......
direct-inward-dial
!--- command on GK-A.
port 1/0:23
prefix 512
h323-gateway voip h323-id [email protected]
!
!--- On outgoing calls through POTS dial-peers,
dial-peer voice 1 voip
!--- all explicit digit matches are dropped,
destination-pattern 512.......
!--- which is the reason
session target ras
!--- for adding the prefix 512. This has nothing to
!
!--- do with technology prefixes.
dial-peer voice 2 pots
destination-pattern 9725551010
!
port 1/0/0
dial-peer voice 2 voip
destination-pattern 972.......
!--- This is the FXS port.
session target ras
!
!--- Uses RAS messages (GK) to get
gateway
!--- call setup information.
!

!
gateway
!

This output captured on GK-A displays the actual registrations. Notice GWY-A2 also registers the E.164 ID of the FXS port.

GK-A#show gatekeeper endpoints

GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type F
--------------- ----- --------------- ----- --------- ---- --
172.22.1.1 1720 172.22.1.1 49317 GK-A VOIP-GW
H323-ID: [email protected]
172.22.1.2 1720 172.22.1.2 58196 GK-A VOIP-GW
E164-ID: 9725551010
H323-ID: [email protected]
Total number of active registrations = 2

First Call Action: User A1 calls user A2 at 972-555-1010. Use the ARQ diagram to complete the decision process.

GK-A receives ARQ from GWY-A1.

1. Does the technology prefix match? No

2. Does the zone prefix match? No

3. Is the arq reject-unknown-prefix command set? No, target-zone equals local zone.

4. Is the target-zone local? Yes

5. Was a technology prefix found in step 1? No

6. Is the target address registered? Yes. Send ACF.

Call setup successful.

Note: GWY-A2 has the destination E.164 ID registered (FXS port). Therefore, the gatekeeper was able to admit the call.

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

GK-A receives ARQ from GWY-A2.

 1. Does the technology prefix match? No

2. Does the zone prefix match? No

3. Is the arq reject-unknown-prefix command set? No, the target-zone equals local zone.

4. Is the target-zone local? Yes

5. Was a technology prefix found in step 1? No

6. Is the target address registered? No

7. Is the default technology prefix set? No. Send ARJ.

Call setup failed.

Note: Scenario 2 explains how to fix this call routing problem with technology prefixes.

Scenario 2: Technology Prefixes Configured

In this scenario, these configuration changes are made:

 GWY-A1—Added the h323-gateway voip tech-prefix 1# command. GWY-A1 registers to the GK-A with technology
prefix 1#.

 GWY-A1—Added a POTS dial-peer with a destination-pattern command that matches the incoming called number
from GWY-A2 with technology prefix 1#.

 GK-A—Added the zone prefix GK-A command. Defines the local zone prefixes GK-A manages.

 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.

GK-A
gatekeeper
zone local GK-A abc.com
zone prefix GK-A 512.......
zone prefix GK-A 972.......
arq reject-unknown-prefix
no shutdown
!
GWY-A1 GWY-A2
!
interface Ethernet0/0
!
ip address 172.22.1.1 255.255.255.0
dial-peer voice 1 voip
h323-gateway voip interface
destination-pattern 512.......
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
session target ras
h323-gateway voip h323-id [email protected]
tech-prefix 1#
h323-gateway voip tech-prefix 1#
!
!
dial-peer voice 2 pots
dial-peer voice 3 pots
destination-pattern 9725551010
incoming called-number 972.......
port 1/0/0
destination-pattern 1#512.......
!
direct-inward-dial
gateway
port 1/0:23
!
prefix 512
interface FastEthernet0/0
!
ip address 172.22.1.2 255.255.255.0
dial-peer voice 2 voip
h323-gateway voip interface
destination-pattern 972.......
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
session target ras
h323-gateway voip h323-id [email protected]
!
!
gateway
!

This output captured on GK-A displays the registered technology prefixes:

GK-A#show gatekeeper gw-type-prefix

GATEWAY TYPE PREFIX TABLE

=========================
Prefix: 1#*
Zone GK-A master gateway list:
172.22.1.1:1720 GW-A1
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.

1. 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.

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

3. Does the alias name (after stripping tech prefix) match with any registered GW? No. (If Yes, send ACF).

4. Is the target-zone local? Yes

5. Was a technology prefix found in step 1? Yes

6. Was a local gateway with a technology prefix found? Yes. Send ACF .

Call setup success.

This GK-A debug command output illustrates the above behavior.

Note: This debug command is a useful, but hidden, debug. Therefore, the parser does not show the debug.

GK-A#debug gatekeeper main 5

*Jun 19 09:50:10.086: gk_rassrv_arq: arqp=0x631CC400, crv=0x82, answerCall=0

*Jun 19 09:50:10.086: gk_dns_locate_gk(): No Name servers
*Jun 19 09:50:10.086: rassrv_get_addrinfo(1#5125551010): Matched tech-prefix 1#
*Jun 19 09:50:10.086: rassrv_get_addrinfo(1#5125551010): Matched zone prefix 512
*Jun 19 09:50:10.118: gk_rassrv_arq: arqp=0x631CC400, crv=0x1A, answerCall=1

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.

Scenario 3: Default Technology Prefixes Configured

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.

GK-A
!
gatekeeper
zone local GK-A abc.com
zone prefix GK-A 512.......
zone prefix GK-A 972.......
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
!
GWY-A1 GWY-A2

!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0 !
h323-gateway voip interface dial-peer voice 1 voip
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718 destination-pattern 512.......
h323-gateway voip h323-id [email protected] session target ras
h323-gateway voip tech-prefix 1# !
! dial-peer voice 2 pots
dial-peer voice 1 pots destination-pattern 9725551010
destination-pattern 512....... port 1/0/0
direct-inward-dial !
port 1/0:23 gateway
prefix 512 !
! interface FastEthernet0/0
dial-peer voice 2 voip ip address 172.22.1.2 255.255.255.0
 destination-pattern 972....... h323-gateway voip interface
session target ras h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
! h323-gateway voip h323-id [email protected]
gateway !
!

This output captured on GK-A displays the registered technology prefixes:

GK-A#show gatekeeper gw-type-prefix

GATEWAY TYPE PREFIX TABLE

=========================
Prefix: 1#* (Default gateway-technology)
Zone GK-A master gateway list:
172.22.1.1:1720 GW-A1

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

GK-A receives ARQ from GWY-A2.

1. Does the technology prefix match? No

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

3. Is the target-zone local? Yes

4. Was a technology prefix found in step 1? No

5. Is the target address registered? No

6. Is the default technology prefix set? Yes. Select the local gateway with the technology prefix (only one available).

7. Send ACF.

Call setup successful.

Remote Zone Call Examples

In these examples, there are two H.323 zones: one controlled by GK-A and another by GK-B.

The scenarios in this section explain the step-by-step decision process the gatekeepers use to route calls based on the ARQ
and LRQ messages.

Note: Only relevant output is shown in these configuration examples.

Scenario 1: Zone Gatekeepers Configured with Default Technology Prefixes

In this scenario, GWY-A1 registers to GK-A with technology prefix 1# and GWY-B1 registers to GK-B with technology prefix
2#. Both gatekeepers are configured with default technology prefix gateways.

GK-A GK-B
!
!
gatekeeper
gatekeeper
zone local GK-A abc.com 172.22.1.3
zone local GK-B abc.com 172.22.2.3
zone remote GK-B abc.com 172.22.2.3 1719
zone remote GK-A abc.com 172.22.1.3 1719
zone prefix GK-B 214.......
zone prefix GK-B 214.......
zone prefix GK-A 512.......
zone prefix GK-A 512.......
gw-type-prefix 1#* default-technology
gw-type-prefix 2#* default-technology
arq reject-unknown-prefix
no shutdown
no shutdown
!
!
GWY-A1 GWY-B1

! !
interface Ethernet0/0 interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0 ip address 172.22.2.1 255.255.255.0
half-duplex h323-gateway voip interface
h323-gateway voip interface h323-gateway voip id GK-B ipaddr 172.22.2.3 1718
 h323-gateway voip id GK-A ipaddr 172.22.1.3 1718 h323-gateway voip h323-id [email protected]
h323-gateway voip h323-id [email protected] h323-gateway voip tech-prefix 2#
h323-gateway voip tech-prefix 1# !
! dial-peer voice 1 pots
dial-peer voice 1 pots destination-pattern 214.......
destination-pattern 512....... direct-inward-dial
direct-inward-dial port 3/0:23
port 1/0:23 prefix 214
prefix 512 !
! dial-peer voice 2 voip
dial-peer voice 2 voip destination-pattern T
destination-pattern .......... session target ras
session target ras !
! gateway
gateway !

Call Action: User A1 dials 214-555-1111 to call user B1.

GK-A receives ARQ from GWY-A1.

1. Does the technology prefix match? No

2. Does the zone prefix match? Yes. Set the target-zone to equal the remote GK-B zone (214).

3. Is the target zone local? No

4. Send LRQ to GK-B.

GK-B receives LRQ from GK-A.

1. Does the technology prefix match? No

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

3. Is the target zone local? Yes

4. Was a technology prefix found in step 1? No

5. Is the target address registered? No

6. Is the default technology prefix set? Yes. Select the local gateway with the technology prefix (2#).

7. Send LCF to GK-A.

GK-A receives LCF from GK-B with terminating gateway information.

GK-A sends ACF to GWY-A1.

The call setup is successful.

Scenario 2: Zone Gatekeepers Configured without Default Technology Prefixes

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).

GK-A GK-B
!
!
gatekeeper
gatekeeper
zone local GK-A abc.com
zone local GK-B abc.com 172.22.2.3
zone remote GK-B abc.com 172.22.2.3 1719
zone remote GK-A abc.com 172.22.1.3 1719
zone prefix GK-B 214*
zone prefix GK-B 214*
zone prefix GK-A 512*
zone prefix GK-A 512*
arq reject-unknown-prefix
no shutdown
no shutdown
!
!
GWY-A1 GWY-B1

! !
interface Ethernet0/0 interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0 ip address 172.22.2.1 255.255.255.0
half-duplex h323-gateway voip interface
h323-gateway voip interface h323-gateway voip id GK-B ipaddr 172.22.2.3 1718
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718 h323-gateway voip h323-id [email protected]
h323-gateway voip h323-id [email protected] h323-gateway voip tech-prefix 2#
h323-gateway voip tech-prefix 1# !
! dial-peer voice 1 pots
dial-peer voice 1 pots destination-pattern 214.......
 destination-pattern 512....... direct-inward-dial
direct-inward-dial port 3/0:23
port 1/0:23 prefix 214
prefix 512 !
! dial-peer voice 2 voip
dial-peer voice 2 voip destination-pattern T
destination-pattern 214....... session target ras
session target ras tech-prefix 1#
tech-prefix 2# !
! gateway
gateway !

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

GK-B receives ARQ from GWY-B1.

1. Does the technology prefix match? No

2. Does the zone prefix match? No

Note: Because GK-B is not aware of a 1# technology prefix, it assumes it is part of the called number and reads it as a
zone prefix.

3. Is the target zone local? Yes

Note: GK-B takes the default target zone equals local zone because the arq reject-unknown-prefix command is not
set.

4. Was a technology prefix found in step 1? No

5. Is the target address registered? No

6. Is the default technology prefix set? No

7. Send ARJ to GWY-B1.

Call setup failed.

This output was captured in GK-B to further illustrate this behavior:

!--- From debug gatekeeper main 5.

GK-B#
gk_rassrv_arq: arqp=0x62F6A7E0, crv=0x22, answerCall=0
gk_dns_locate_gk(): No Name servers
rassrv_get_addrinfo(1#5125551212): Tech-prefix match failed
rassrv_get_addrinfo(1#5125551212): unresolved zone prefix, using source zone GK-B
rassrv_get_addrinfo(1#5125551212): unknown address and no default technology defined
gk_rassrv_sep_arq(): rassrv_get_addrinfo() failed (return code = 0x103)

!--- From debug ras.

GK-B#
RecvUDP_IPSockData successfully rcvd message of length 156 from 172.22.2.1:51141
ARQ (seq# 1796) rcvdparse_arq_nonstd: ARQ Nonstd decode succeeded, remlen= 156
IPSOCK_RAS_sendto: msg length 4 from 172.22.2.3:1719 to 172.22.2.1: 51141
RASLib::RASSendARJ: ARJ (seq# 1796) sent to 172.22.2.1

Configure the gatekeepers to identify the remote zone technology prefixes in order to fix this problem.

 Add this to GK-B:

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

 Add this to GK-A:

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

Notice that the POTS dial-peer in the terminating gateways needed to be updated to match the incoming dial strings with the
technology prefixes.

GK-A GK-B

!
gatekeeper !
zone local GK-A abc.com gatekeeper
 zone remote GK-B abc.com 172.22.2.3 1719 zone local GK-B abc.com 172.22.2.3
zone prefix GK-B 214* zone remote GK-A abc.com 172.22.1.3 1719
zone prefix GK-A 512* zone prefix GK-B 214*
arq reject-unknown-prefix zone prefix GK-A 512*
gw-type-prefix 2# hopoff GK-B gw-type-prefix 1# hopoff GK-A
no shutdown no shutdown
! !
GK-B GWY-B1
!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0
half-duplex
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id [email protected]
h323-gateway voip tech-prefix 1#
!
!
interface Ethernet0/0
!--- This dial-peer is used for
ip address 172.22.2.1 255.255.255.0
!--- incoming calls from the PSTN.
h323-gateway voip interface
h323-gateway voip id GK-B ipaddr 172.22.2.3 1718
dial-peer voice 1 pots
h323-gateway voip h323-id [email protected]
incoming called-number 512.......
h323-gateway voip tech-prefix 2#
direct-inward-dial
!
port 1/0:23
dial-peer voice 1 pots
!
incoming called-number 214.......
dial-peer voice 2 voip
direct-inward-dial
destination-pattern 214.......
port 3/0:23
session target ras
prefix 214
tech-prefix 2#
!
!
dial-peer voice 2 voip
destination-pattern T
!--- This dial-peer is used to
session target ras
!--- terminate (512) calls coming
tech-prefix 1#
!--- from the VoIP network. Notice
!
!--- that the technology prefix
dial-peer voice 3 pots
!--- is matched to select the dial-peer
destination-pattern 2#214.......
!--- but does not pass it to
port 3/0:23
!--- the PSTN.
prefix 214
!
dial-peer voice 3 pots
gateway
destination-pattern 1#512.......
!
direct-inward-dial
port 1/0:23
prefix 512
!
dial-peer voice 4 voip
destination-pattern 972.......
session target ras
!
gateway

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

GK-B receives ARQ from GWY-B1.

1. Does the technology prefix match? Yes

2. Is there a hop-off technology prefix? Yes

3. Send LRQ to GK-A.

Note: The LRQ includes the technology prefix in the called number for GK-A analysis.

GK-A receives LRQ from GK-B.

1. Does the technology prefix match? Yes

2. Is there a hop-off technology prefix? No

Note: In order to continue the call routing analysis, GK-A strips the technology prefix. The technology prefix does
remain in the called number string when the gateways set up the call legs.

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

4. Is the target-zone local? Yes

 5. Was a technology prefix found in step 1? Yes

6. Did you find a local gateway with a technology prefix? Yes

7. Send LCF to GK-B.

GK-B receives LCF from GK-A with terminating gateway information.

GK-B sends ACF to GWY-B1.

Call setup successful.

This command output was captured in GK-B to further illustrate this behavior:

!--- From debug gatekeeper main 5.

GK-B#
gk_rassrv_arq: arqp=0x62ED2D68, crv=0x24, answerCall=0
gk_dns_locate_gk(): No Name servers
rassrv_get_addrinfo(1#5125551212): Matched tech-prefix 1#
rassrv_put_remote_zones_from_zone_list() zone GK-A
gk_rassrv_irr: irrp=0x62F0D8FC, from 172.22.2.1:51141
GK-B#
GK-B#

!--- From debug ras.

RecvUDP_IPSockData successfully received message of

length 156 from 172.22.2.1:51141
ARQ (seq# 1809) rcvdparse_arq_nonstd: ARQ Nonstd decode
succeeded, remlen= 156
IPSOCK_RAS_sendto: msg length 104 from
172.22.2.3:1719 to 172.22.1.3: 1719
RASLib::RASSendLRQ: LRQ (seq# 1042) sent to 172.22.1.3
IPSOCK_RAS_sendto: msg length 7 from 172.22.2.3:1719 to 172.22.2.1: 51141
RASLib::RASSendRIP: RIP (seq# 1809) sent to 172.22.2.1
RecvUDP_IPSockData successfully rcvd message of length
131 from 172.22.1.3:1719
LCF (seq# 1042) rcvdparse_lcf_nonstd: LCF Nonstd
decode succeeded, remlen= 131
IPSOCK_RAS_sendto: msg length 34 from 172.22.2.3:1719
to 172.22.2.1: 51141
RASLib::RASSendACF: ACF (seq# 1809) sent to 172.22.2.1
RecvUDP_IPSockData successfully rcvd message of length
76 from 172.22.2.1:51141

Verification and Troubleshooting Commands

This section provides a list of show and debug commands that are used to verify and troubleshoot gatekeeper and gateway
call routing issues.

The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an
analysis of show command output.

Note: Refer to Important Information on Debug Commands before you use debug commands.

 show gateway—Used to verify E.164 and H.323 alias registration for the gateway.

 show gatekeeper endpoints—Used to verify the E.164 and H.323 alias registered with the gatekeeper.

 show gatekeeper gw-type-prefix—Used to verify E.164 prefix registrations on the gatekeeper.

 show gatekeeper zone prefix | status—Used to verify zone status and configuration parameters.

 debug ras—Applicable for gateways and gatekeepers.

 debug h225 asn1—Applicable for gateways and gatekeepers.

 show dial-peer voice—Used to verify configured technology prefixes under the dial-peers.

Cisco Support Community - Featured Conversations

Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your
peers. Below are just some of the most recent and relevant conversations happening right now.
 Want to see more? Join us by clicking here

Can Cisco IOS Gatekeeper do call... d-tay 2 Replies 7 years, 7 months ago

H.323 Gatekeeper Enquiry Hunt.Lee_at_telecom.co.nz 1 Reply 6 years, 6 months ago

Can a Gatekeeper do call admission... d-tay 1 Reply 7 years, 7 months ago

3620 h323 gatekeeper MRTG monitor... samuel.lam 1 Reply 6 years, 3 months ago

H.323 Gatekeeper Call Rates fadilaimy 1 Reply 7 years, 1 month ago

H.323 Gatekeeper on Cisco 2811 boonchin.ng 12 Replies 1 year, 6 months ago

7980 video call to a H323... datng 1 Reply 1 month, 2 weeks ago

Gatekeeper Cisco X H323 Gatekeepers s.uziel 0 Replies 8 years, 3 weeks ago

H.323 Gatekeeper for dummies. SludnevTN 2 Replies 1 year, 8 months ago

PIX protecting H323 IOS Gateway with... cperroquin 7 Replies 5 years, 10 months ago

Start A New Discussion Subscribe

Related Information

 Understanding H.323 Gatekeepers

 Troubleshooting Gatekeeper Registration Issues
 Voice - Understanding How Inbound and Outbound Dial Peers are Matched on Cisco IOS Platforms
 Voice Technology Support
 Voice and Unified Communications Product Support

 Troubleshooting Cisco IP Telephony

 Technical Support & Documentation - Cisco Systems

Updated: Jan 04, 2007 Document ID: 24462

Contacts | Feedback | Help | Site Map

© 1992-2010 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.