Cisco Voice Guru » H.323 RAS

Gatekeeper Troubleshooting Notes

Matthew Berry — Thu, 22 Jul 2010 11:38:21 +0000

Most of the content from this troubleshooting post was gathered from the H.323 Gatekeeper Troubleshooting document on Cisco’s docwiki site. I have tried to summarize the important points below. Thanks to Zen Beck for pointing me in the right direction.

Troubleshooting H.323 Gatekeeper Registration

To determine registration reject issues, run a “debug h225 asn1” and search for “rejectReason.” Below is a list of the registration reject reasons and corresponding explanations:

RRJ: rejectReason duplicateAlias

This is usually the result of the gateway registering a duplicate of an E164-ID or H323-ID-another gateway has already been registered to the gatekeeper. If it is a duplicated E164-ID, change the destination pattern configured under a POTS dial-peer associated with an FXS port. If it is a duplicated H323-ID, change the gateway’s H.323 ID under the H.323 VoIP interface.

RRJ: rejectReason terminalExcluded

This is the result of the gateway subnet being disabled in the gatekeeper. Check the gatekeeper configuration. Removing the “no zone subnet gk” command resolves the issue. To remove the command completely, remove the “zone local gk” command.

RRJ: rejectReason securityDenial

This RRJ is the result of the security commands being enabled in the gatekeeper, and the inability of the gateway to match the H.323-ID, E.164-ID, passwords, or security token that the gatekeeper requires. To resolve the issue, check the securiy configuration in the gatekeeper.

RRJ: rejectReason invalidAlias

The RRJ is the result of a no-zone prefix defined in the gatekeeper. Check the configuration on the gatekeeper and add the zone prefix with the proper E.164 address.

Troubleshooting H.323 Gatekeeper Call Routing and Dial Peers

The following is a list of useful show and debug commands used to verify and troubleshoot gatekeeper and gateway call routing issues.

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 debug h225 asn1 - Applicable for gateways and gatekeepers
show dial-peer voice - Used to verify configured technology prefixes under the dial-peers

Troubleshooting H.323 Gatekeeper Bandwidth

When deciding whether there is enough bandwidth to accept a call Admission Request (ARQ), the Cisco gatekeeper calculates the available bandwidth with the following formula:

Available bandwidth = (total allocated bandwidth) – (bandwidth used locally) – (bandwidth used by all alternates).

If the available bandwidth is sufficient for the call, an Admission Confirmation (ACF) is returned, otherwise an Admission Rejection (ARJ) is returned.

Three show commands give you visibility into the bandwidth management on the gatekeeper:

show gatekeeper zone status
show gatekeeper zone cluster
show gatekeeper calls

Troubleshooting Gatekeeper Endpoint Call Admission Issues

Admission Confirmed (Busy Tone Back)

If the Admission Confirmed (ACF) message has been sent by the gatekeeper and arrived at the endpoint side, but the call still received a busy signal, check to see if the terminating IP address in the ACF is an expected valid endpoint IP. If the ACF has an IP address of the terminating endpoint, remove the gatekeeper and make a direct endpoint-to-endpoint call to see if a call can be established.

Admission Reject (ARJ) rejectReason calledPartyNotRegistered

This is a common reason for rejection. It is captured from the local or originating gatekeeper when the gatekeeper has no information on where the called number should be terminated. There are two ways this problem can occur. One reason is that the call terminates at a gateway, and the gateway is not registered with the E.164 address or with a tech-prefix. To resolve this, make sure the gateway is registered with a tech-prefix to the gatekeeper.

A second possible explanation for this error message arises if the called party is a terminal in a remote zone. It might be that the terminal does not have a proxy enabled in the same gatekeeper zone where it is registered.

Note: Intrazone calls do not require the match of a zone prefix.

ARJ "rejectReason requestDenied"

The rejection shown here comes about because the endpoint-requested bandwidth exceeds the limit configured in the gatekeeper. To resolve this, increase the bandwidth in the gatekeeper using the “bandwidth” command under the gatekeeper mode, or lower the bandwidth request from the endpoint.

Refer to the “debug h225 asn1” for the requested bandwidth in the ARQ (Search for “admissionRequest” in the otuput). Compare requested value to the “gatekeeper zone status” to see if enough bandwidth is available.

CSCsl74701 Bug Details

Matthew Berry — Fri, 21 May 2010 19:14:25 +0000

I got burned by this bug last night. Read up on it and be aware of what you might run into with CUCM 7.0(1) on the lab!

CSCsl74701 Bug Details
ARQ requests 1280 when no regions are defined to use g711

Symptom:
ARQ sent to gatekeeper requests bandwidth for a g711 call (1280) even though only g729 is configured in all of the regions.

Conditions:
In a call routed to a GK controlled ICT and all regions are configured for g729, the originating CCM requests 160 in the ARQ to the gatekeeper. When the h225 setup arrives at the terminating CCM, an ARQ is sent to the gatekeeper requesting 1280. This is because the IntraAudioRegionDefault and InterAudioRegionDefault service paramater settings are included in the calculation for the maximum bandwidth request. Callmanager default setting for IntraAudioRegionDefault is g711.

It should check region pair before applying default if there is nothing matched.

Workaround:
Set both service parameters to g729, or increase zone bandwidth setting on the gatekeeper

Debug RAS

Matthew Berry — Wed, 12 May 2010 16:00:23 +0000

HQ-RTR#debug ras
H.323 RAS Messages debugging is on
HQ-RTR#
STEP ONE: ARQ received from BR2 gateway – “I’m dumb. Does this guy exist and can I talk to him? Gatekeeper, help me.”
May 12 15:17:12.357: RecvUDP_IPSockData successfully rcvd message of length 200 from 10.10.112.2:50555
May 12 15:17:12.357: ARQ (seq# 1989) rcvdparse_arq_nonstd: ARQ Nonstd decode succeeded, remlen = 1134656188
STEP TWO: ACF sent to BR2 gateway
May 12 15:17:12.361: IPSOCK_RAS_sendto:   msg length 86 from 10.10.110.1:1719 to 10.10.202.1: 50555
May 12 15:17:12.361:       RASLib::RASSendACF: ACF (seq# 1989) sent to 10.10.202.1
STEP THREE: ARQ from CUCM trunk
May 12 15:17:12.381: RecvUDP_IPSockData successfully rcvd message of length 110 from 10.10.210.11:32804
May 12 15:17:12.385: ARQ (seq# 3846) rcvd
STEP FOUR: ACF sent to CUCM trunk - “Yes, moron, you can talk to this gateway.”
May 12 15:17:12.385: IPSOCK_RAS_sendto:   msg length 24 from 10.10.110.1:1719 to 10.10.210.11: 32804
May 12 15:17:12.385:       RASLib::RASSendACF: ACF (seq# 3846) sent to 10.10.210.11
STEP FIVE: Call is established between gateway and CUCM trunk – “Yay, we’re two dumb gateways talking to each other!”
May 12 15:17:12.397: h323chan_chn_process_read_socket
May 12 15:17:12.397: h323chan_chn_process_read_socket: fd=0 of type LISTENING has data
May 12 15:17:12.397: h323chan_chn_process_read_socket
May 12 15:17:12.397: h323chan_chn_process_read_socket: fd=2 of type ACCEPTED has data
May 12 15:17:12.397: h323chan_chn_process_read_socket: h323chan accepted/connected fd=2
May 12 15:17:15.629: h323chan_chn_process_read_socket
May 12 15:17:15.629: h323chan_chn_process_read_socket: fd=2 of type ACCEPTED has data
May 12 15:17:15.629: h323chan_chn_process_read_socket: h323chan accepted/connected fd=2
STEP SIX: DRQ received from CUCM trunk - “Can I be done talking to this gateway?“
May 12 15:17:18.833: RecvUDP_IPSockData successfully rcvd message of length 272 from 10.10.210.11:32804
May 12 15:17:18.833: DRQ (seq# 3847) rcvd
STEP SEVEN: DCF sent to CUCM trunk- “Sure, you can disconnect the call now. I give you permission because I (gatekeeper) have the power.”
May 12 15:17:18.833: IPSOCK_RAS_sendto:   msg length 3 from 10.10.110.1:1719 to 10.10.210.11: 32804
May 12 15:17:18.833:       RASLib::RASSendDCF: DCF (seq# 3847) sent to 10.10.210.11
STEP EIGHT: DRQ received from BR2 gateway - “Can I be done talking to this CUCM trunk?”
May 12 15:17:18.849: RecvUDP_IPSockData successfully rcvd message of length 108 from 10.10.112.2:50555
May 12 15:17:18.853: DRQ (seq# 1991) rcvdparse_rasusginfo_nonstd: Ras Usage Info Nonstd decode succeeded, remlen = 1221266776
STEP NINE: DCF sent to BR2 gateway – “Sure, you can disconnect the call now. I give you permission because I (gatekeeper) have the power.”
May 12 15:17:18.853: IPSOCK_RAS_sendto:   msg length 3 from 10.10.110.1:1719 to 10.10.202.1: 50555
May 12 15:17:18.853:       RASLib::RASSendDCF: DCF (seq# 1991) sent to 10.10.202.1

Configuring RAS Retries and Timers

Matthew Berry — Thu, 11 Feb 2010 11:46:53 +0000

I am reading in the Cisco IOS H.323 Configuration guide this morning. Yes, it’s exhilarating to read at 5:00am (NOT!). Since I’m nodding off to sleep, I am writing another post to pass on the next bit of knowledge – configuring RAS retries and timers.

Normally, you would never need to touch this piece of H.323 gateways, but we’re not dealing with “normal,” real-world experience. We’re dealing with the psychotic CCIE voice lab. You need to know everything.

RAS Configuration Options

The ras timeout command configures the number of seconds for the gateway to wait before resending a RAS message to a gatekeeper.

The ras retry command configures the number of times to resend the RAS message after the timeout period expires.

The ras rrq ttl command configures the number of seconds that the gateway should be considered active by the gatekeeper. The gateway transmits this value in the RRQ message to the gatekeeper. The margin time keyword and argument allow the gateway to transmit an early RRQ to the gatekeeper before the time-to-live value advertised to the gatekeeper.

The default values for timeouts and retries are acceptable in most networks. You can use these commands if you are experiencing problems in RAS message transmission between gateways and gatekeepers.

RAS Configuration Example

voice service voip
h323
ras timeout {all | arq | brq | drq | grq | rai | rrq} value
ras retry {all | arq | brq | drq | grq | rai | rrq} value
ras rrq ttl time-to-live [margin time]
exit

Debug RAS Command

Matthew Berry — Thu, 11 Feb 2010 11:37:03 +0000

Usage Guidelines

Use the debug ras command to display the types and addressing of RAS messages sent and received. The debug output lists the message type using mnemonics defined in International Telecommunications Union-Telecommunication (ITU-T) specification H.225.
Examples

Practical Example

In the following output, gateway GW13.cisco.com sends a RAS registration request (RRQ) message to gatekeeper GK15.cisco.com at IP address 10.9.53.15. GW13.cisco.com then receives a registration confirmation (RCF) message from the gatekeeper.

If there is no response, it could mean that the gatekeeper is offline or improperly addressed.

If you receive a reject (RRJ) message, it could mean that the gatekeeper is unable to handle another gateway or that the registration information is incorrect.

Router# debug ras
*Mar 13 19:53:34.231: RASlib::ras_sendto:msg length 105 from 10.9.53.13:8658 to 10.9.53.15:1719
*Mar 13 19:53:34.231: RASLib::RASSendRRQ:RRQ (seq# 36939) sent to 10.9.53.15
*Mar 13 19:53:34.247: RASLib::RASRecvData:successfully rcvd message of length 105 from 10.9.53.15:1719
*Mar 13 19:53:34.251: RASLib::RASRecvData:RCF (seq# 36939) rcvd from [10.9.53.15:1719] on sock [0x6168356C]

Shutting Down and Enabling VoIP Services

Matthew Berry — Wed, 10 Feb 2010 03:33:57 +0000

This is just a thought, but I wouldn’t be surprised to see the proctor try to “pull a fast one” by shutting down VoIP services on an H.323 gateway. I suppose this could be easily identified by executing a “show gateway” or “show run.” I came across this while reading the Cisco IOS H.323 Configuration Guide.

Shutting Down and Enabling VoIP Service

To shut down or enable all VoIP services on a Cisco gateway:

voice service voip
(no) shutdown forced
exit

The following example displays output after the gateway has been shut down:

Router# show gateway
H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1
H.323 service is shutdown
Gateway Router is not registered to any gatekeeper

Shutting Down and Enabling VoIP Submodes

To shut down or enable VoIP submodes on a Cisco gateway:

voice service voip
h323
(no) call service stop maintain-registration
exit

The following example displays output when H.323 call service has been shut down with the call service stop maintain-registration command:

Router# show gateway
H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1
H.323 service is shutdown
Gateway Router is registered to Gatekeeper GK1

debug gatekeeper main 10

Matthew Berry — Mon, 08 Feb 2010 13:00:41 +0000

H.323 gatekeepers can be a difficult topic to approach. Most people have not integrated this into their environment and, therefore, have little hands-on experience deploying and troubleshooting this technology. Personally, I think the idea of a gatekeeper is a pretty cool concept. If using H.323 gateways, it can make your dial plan management a whole lot simpler.

One of the frustrations related to using gatekeepers is the lack of debugging available. Fear not, my friend! I recently stumbled across an undocumented debug command that will make your gatekeeper work easier: debug gatekeeper main 10

In this scenario, I placed a call from extension 3002 at a remote-site CUCME to extension 5002 in a CUCM cluster. Calls are routing to the gatekeeper via an H.225 RAS dial peer, with tech-prefix of #1:

@@@ Turn on gatekeeper debugging
HQ-RTR#debug gatekeeper main 10
HQ-RTR#
*Feb 7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
*Feb 7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48D839A0,crv=0x1A, answerCall=0
*Feb 7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_sep_arq: ARQ Didn’t use GK_AAA_PROC
*Feb 7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/gk_dns_query: No Name servers

@@@ At this point, 1#5002 was received by the gatekeeper. It saw that #1 was a tech-prefix for an H.225 gatekeeper-controlled trunk in CUCM that is registered to the gatekeeper.
*Feb 7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_get_addrinfo: (1#5002) Matched tech-prefix 1#

@@@ At this point, the gatekeeper goes on to the next section of digits “5002.” It looks in its tables and sees that “zone prefix 5…” directs these calls to the H.225 gatekeeper-controlled trunk in CUCM
*Feb 7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_get_addrinfo: (1#5002) Matched zone prefix 5 and remainder 002

@@@ RAS admission requests are sent to the side sourcing the call.
*Feb 7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
*Feb 7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x48D06EAC
*Feb 7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: matched zone is PL, and z_invianamelen=0

@@@ RAS admission requests are sent to the side receiving the call.
HQ-RTR#7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x48D06EAC
*Feb 7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: matched zone is PL, and z_outvianamelen=0
*Feb 7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1

@@@ RAS bandwidth requests are sent
HQ-RTR#
*Feb 7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
*Feb 7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_brq: state = 0xF
*Feb 7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_brq: brqp=0x48D80C84, crv=0x1A, bandWidth=160

@@@ RAS information requests are sent
*Feb 7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
*Feb 7 20:28:26.522: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_irr: irrp=0x48D80ED0, from 10.10.110.3:54771
HQ-RTR#
*Feb 7 20:28:32.122: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: got a TIMER event
*Feb 7 20:28:32.122: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_handle_timers
*Feb 7 20:28:32.122: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_handle_timers: managed timer expired 0x467C9258

Gatekeeper Reflections

Matthew Berry — Mon, 08 Feb 2010 12:43:14 +0000

Yesterday, I worked on some gateway and gatekeeper exercises using IPexpert’s workbooks and ProctorLabs remote racks. During my exercises, I had an issue with calls being routed from a CUCME H.323-configured gateway, through the HQ gatekeeper, and on to CUCM via H.225 gatekeeper-controlled trunk. When I would place a call from the remote CUCME, I would get a message from the CUCM annunciator saying, “Your call cannot be completed as dialed.” In the end, all I needed to do was reset the H.225 trunk in CUCM. However, there were a few things I learned/saw along the way that were worth putting up on the site.

Lesson 1: Gatekeepers don’t change digit strings

Remember this mantra: “Whatever going in the gatekeeper, leaves the gatekeeper.” Whatever digits your gateway sends out will be received on the other end. A call passing through a 3rd party device (i.e. gatekeeper) does not necessitate a transformation. If I send #15002 (i.e. tech prefix + number) from my CUCME remote gateway, that is what CUCM will receive on the other end. Therefore, I need to configure the H.225 gatekeeper-controlled trunk in CUCM to discard the tech prefix (e.g. #1) by setting significant digits to 4. This tells CUCM to only process the rightmost four digits. #15002 becomes 5002 and the #1 is discarded.

Lesson 2: Use RAS debugging

H.225.0 call control signaling is used to setup connections between H.323 endpoints. This is achieved by exchanging H.225 protocol messages on the call-signaling channel.

H.225.0/RAS (Registration, Admission and Status) is the protocol between endpoints (terminals and gateways) and gatekeepers. The RAS is used to perform registration, admission control, bandwidth changes, status, and disengage procedures between endpoints and gatekeepers. An RAS channel is used to exchange RAS messages. This signaling channel is opened between an endpoint and a gatekeeper prior to the establishment of any other channels.

HQ-RTR#debug ras
H.323 RAS Messages debugging is on
@@@ I place a call from CUCME remote gateway to CUCM, using H.225 RAS Dial Peer
HQ-RTR#
*Feb 7 20:32:28.702: RecvUDP_IPSockData successfully rcvd message of length 205 from 10.10.110.3:54771
*Feb 7 20:32:28.702: ARQ (seq# 155) rcvdparse_arq_nonstd: ARQ Nonstd decode succeeded, remlen = 1134656188
*Feb 7 20:32:28.706: IPSOCK_RAS_sendto:   msg length 83 from 10.10.110.1:1719 to 10.10.110.3: 54771
*Feb 7 20:32:28.706:       RASLib::RASSendACF: ACF (seq# 155) sent to 10.10.110.3
HQ-RTR#
*Feb 7 20:32:35.946: RecvUDP_IPSockData successfully rcvd message of length 80 from 10.10.110.3:54771
*Feb 7 20:32:35.946: BRQ (seq# 156) rcvd
*Feb 7 20:32:35.946: IPSOCK_RAS_sendto:   msg length 5 from 10.10.110.1:1719 to 10.10.110.3: 54771
*Feb 7 20:32:35.946:       RASLib::RASSendBCF: BCF (seq# 156) sent to 10.10.110.3
*Feb 7 20:32:35.946: RecvUDP_IPSockData successfully rcvd message of length 176 from 10.10.110.3:54771
*Feb 7 20:32:35.950: IRR (seq# 157) rcvdparse_prCll_nonstd: prCll Nonstd decode succeeded, remlen = 1134656188
@@@ I answer the call, leave connected for 10 seconds, and then terminate the call
*Feb 7 20:32:49.522: RecvUDP_IPSockData successfully rcvd message of length 108 from 10.10.110.3:54771
*Feb 7 20:32:49.522: DRQ (seq# 158) rcvdparse_rasusginfo_nonstd: Ras Usage Info Nonstd decode succeeded, remlen = 1220674372
*Feb 7 20:32:49.526: IPSOCK_RAS_sendto:   msg length 3 from 10.10.110.1:1719 to 10.10.110.3: 54771
*Feb 7 20:32:49.526:   RASLib::RASSendDCF: DCF (seq# 158) sent to 10.10.110.3
HQ-RTR#

Key RAS messages:

RegistrationRequest (RRQ)
Request from a terminal or gateway to register with a gatekeeper. Gatekeeper either confirms or rejects (RCF or RRJ).
AdmissionRequest (ARQ)
Request for access to packet network from terminal to gatekeeper. Gatekeeper either confirms or rejects (ACF or ARJ).
BandwidthRequest (BRQ)
Request for changed bandwidth allocation, from terminal to gatekeeper. Gatekeeper either confirms or rejects (BCF or BRJ).
DisengageRequest (DRQ)
If sent from endpoint to gatekeeper, DRQ informs gatekeeper that endpoint is being dropped; if sent from gatekeeper to endpoint, DRQ forces call to be dropped. Gatekeeper either confirms or rejects (DCF or DRJ). If DRQ sent by gatekeeper, endpoint must reply with DCF.
InfoRequest (IRQ)
Request for status information from gatekeeper to terminal.
InfoRequestResponse (IRR)
Response to IRQ. May be sent unsolicited by terminal to gatekeeper at predetermined intervals.
RAS timers and Request in Progress (RIP)
Recommended default timeout values for response to RAS messages and subsequent retry counts if response is not received.

Hardcoding H.225 Trunk Signaling Ports in CUCM

Matthew Berry — Fri, 05 Feb 2010 03:00:47 +0000

If you’re using an IOS gateway, you’re in luck because the port number will be consistent. These ports are set to 1720 and 1719 on the gatekeeper by default. This includes CUCME systems that you are registering to a gatekeeper.

When a H.225 Gatekeeper Controlled Trunk registers with an H.323 Gatekeeper, CUCM will dynamically assign port numbers for gateway signaling and for RAS. If you don’t do this and the proctor resets your Trunks before grading (or maybe he/she even reboots the CCM box), then you’re screwed big-time.

You can verify the Signalling and RAS ports CCM registered with on the gatekeeper with the show gatekeeper endpoints command:

GK-RTR#sh gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr   Port Zone Name         Type    Flags
————— —– ————— —– ———         —-    —–
10.10.50.103    2789 10.10.50.103    4318 gk-zone1          VOIP-GW
H323-ID: gk-trunk_1
Voice Capacity Max.= Avail.= Current.= 0
172.16.30.254   1720 172.16.30.254   57634 gk-zone1          VOIP-GW
H323-ID: CME_Trunk
Voice Capacity Max.= Avail.= Current.= 0
Total number of active registrations = 2

There isn’t much configuration needed to get this working; however, for your configuration to “stay working“, you would need to “hardcode” the signalling port used by your GK-Controlled Trunk in CUCM to always use port 1720 as its Gateway Signalling Port.

This is quite important because CCM dynamically assigns port numbers for gateway signalling and for RAS. These ports are set to 1720 and 1719 respectively on the gatekeeper by default.

As shown above, CME registers with 1720 by default, but CCM registers with 2789. If CCM_GKCT trunk is reset, the port number would change to something totally different. To configure CCM to use the port 1720 (signalling port) for a particular gatekeeper-controlled trunk through the CCM Service Parameters: “Device Name of GK-Controlled Trunk That Will Use Port 1720″. This is a clusterwide service parameter.

In the field, enter the exact name (case-sensitive) of the H.225 trunk created in CUCM. The H.225 trunk will create pseudo-virtual “sub-trunks,” one for each CUCM call processing server in the CUCM group that is defined in the device pool assigned to the trunk. The naming convention of these H.225 trunks is based off the order each CUCM call processing server was added to the cluster. Naturally, the publisher will always be “_1″.

For example, if you named the H.225 trunk “gk-trunk” and put it in a device pool that had a publisher and subscriber, you would have two gatekeeper-definable trunks called: “gk-trunk_1″ (Publisher) and “gk-trunk_2″ (Subscriber).

Much of this information was sourced from http://skybaba.wordpress.com

Zone Prefix Processing – Dots vs. Asterisks

Matthew Berry — Thu, 04 Feb 2010 17:45:57 +0000

Problem:

When you have a gatekeeper configured with zones that contain overlapping dial-plans, you need to be cognizant of your use of dots and asterisks in zone statements. Otherwise, you will create (as Cisco puts it) “ambiguous situations” in which the gatekeeper will not know which zone or gateway it should send a call to.

For example:

gatekeeper
zone local localzone1 dns.au 10.1.1.228zone local localzone2 dns.au
no zone subnet localzone1 default enable
zone subnet localzone1 10.1.1.240/28 enable
no zone subnet localzone2 default enable
zone subnet localzone2 10.99.0.0/16 enable
zone prefix localzone1 0*
zone prefix localzone1 1*
zone prefix localzone1 6*
zone prefix localzone1 8*
zone prefix localzone2 9999931..
Zone prefix localzone2 9999932..
Zone prefix localzone2 9999933..
Zone prefix localzone2 9999934..
Zone prefix localzone2 9999935..
Zone prefix localzone2 9999936..
Zone prefix localzone2 9999937..
Zone prefix localzone2 9999938..
Zone prefix localzone2 9999939..
Zone prefix localzone2 999994…
zone prefix localzone2 999995…
zone prefix localzone1 9*
accounting vsa
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
lrq reject-unknown-prefix
no use-proxy localzone2 default inbound-to terminal
no use-proxy localzone2 default outbound-from terminal
no shutdown
endpoint ttl 60

Symptoms and Characteristics:

The local gatekeeper is expected to route calls to more than one local zone or is expected to route calls to gatekeepers in remote zones or both.
Calls within a local zone can be routed successfully.
Some, but not all, interzone calls can be routed successfully.
The interzone calls that are not routed successfully are to called numbers with a specific number of digits. For example, calls to a 10-digit or nine-digit number may succeed, while a call to a three-digit number starting with the same digit reliably fails.
The gatekeeper configuration makes use of dot wildcards within zone prefixes.

Solution:

When you specify wildcard digits within a zone prefix, avoid using dots where possible. Instead, use the less-specific asterisk wildcard. You can also avoid the problem when you observe these rules:

If the dial-plan is consistent, you can use a configuration with only dots (or using only asterisks).
If there is an overlap in the dial-plan, it is best to stick to using configurations with asterisks.
If there is overlap in the dial-plan, and a configuration with only asterisks is not suitable, study the gatekeeper’s default behavior of prefix guessing (deduce and prepend the local area code) before you configure the gatekeeper.

The third rule requires an understanding of the details of the gatekeeper’s behavior as described in this document.

Debug Examples:

This is debug output from the gatekeeper that shows Registration, Admission, and Status Protocol (RAS) flows and zone prefix processing for:

debug h225 asn1 and debug gatekeeper main 10 – failed call

GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!— This output is from the debug h225 ans1 command issued on the gatekeeper. It shows
!— an incoming RAS ARQ for called number 112. It is important to
!— note that the calling number (source endpoint) comes from the zone localzone2 and,
!— assuming three-digit numbers, its prefix (source endpoint prefix) is 999995.

Mar 11 21:48:15: RAS INCOMING PDU ::=

value RasMessage ::= admissionRequest :
{
requestSeqNum 36784
callType pointToPoint : NULL
callModel gatekeeperRouted : NULL
endpointIdentifier {“618FED9800000008″}
destinationInfo
{
e164 : “112″,
e164 : “112″
}
srcInfo
{
h323-ID : {“999995985″},
e164 : “999995985″
}
srcCallSignalAddress ipAddress :
{
ip ’0A14000C’H
port 11309
}
bandWidth 1280
callReferenceValue 31633
conferenceID ’5634343434EF21002B211E5226E91D26′H
activeMC FALSE
answerCall FALSE
canMapAlias FALSE
callIdentifier
{
guid ’5634343434EF20002B211E5226E91D26′H
}
gatekeeperIdentifier {“localzone2″}
willSupplyUUIEs FALSE
}

!— This output is from the debug gatekeeper main 10 command
!— issued on the gatekeeper. It
!— shows the gatekeeper zone prefix processing logic (rassrv_get_addrinfo).
!— Comments are inserted throughout.

Mar 11 21:48:15: gk_rassrv_arq: arqp=0x61A09EE4, crv=0x7B91, answerCall=0
Mar 11 21:48:15: ARQ Didn’t use GK_AAA_PROC

!— Tech-prefix matching occurs first. In this case study, no
!— tech-prefixes are configured so no match is found.

Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.

!— The next line in the trace is the key to what, in this case study, is unexpected
!— behavior. The expected behavior is for 112 to match with the wildcard “1*” entry
!— in localzone1.

!— The local (source) zone of the calling number is localzone2.
!— It has been configured as
!— supporting the prefix “999995…” with three wildcard digits.
!— (Note the configuration line
!— “zone prefix localzone2 999995…”.)

!— The gatekeeper, when asked to resolve a three-digit number 112,
!— deduces this to mean “999995-112″ in the local zone because
!— “112″ matches with the specific-length three-dot
!— wildcard configuration for the local zone.

!— This behavior is exactly the same as a local area code being assumed when a local
!— call is made.

!— If the configuration line “zone prefix localzone2 999995…” was removed from the
!— configuration, or if the line “zone prefix localzone2 999995*” was inserted instead,
!— then the three-digit number “112″ would not match in the local
!— zone but would rather match localzone1 through the
!— configuration line “zone prefix localzone1 1*”.

Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint’s zone prefix 999995

Mar 11 21:48:15: No tech-prefix

Mar 11 21:48:15: Alias not found

!— The gatekeeper attempts to find a default technology prefix, But although “#1″ is
!— configured, the H.323 endpoints in localzone2 correctly do not register with that. The
!— conclusion drawn is that there is an “unknown address and no default
!— technology defined”:

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0×805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Tech-prefix match failed.
Mar 11 21:48:15: rassrv_get_addrinfo(112): Defaulting to source endpoint’s zone prefix 999995
Mar 11 21:48:15: No tech prefix

Mar 11 21:48:15: Alias not found

!— The gatekeeper indicates that it has failed to find a registered match for the
!— called number in localzone2:

Mar 11 21:48:15: rassrv_get_addrinfo(112): default-tech gateway selection failed, status = 0×805
Mar 11 21:48:15: rassrv_get_addrinfo(112): unknown address and no default technology defined.
Mar 11 21:48:15: gk_rassrv_sep_arq(): rassrv_get_addrinfo() failed (return code = 0×103)

!— The gatekeeper sends the Admission Reject (ARJ) because the called party is not
!— registered:

Mar 11 21:48:15: RAS OUTGOING PDU ::=

value RasMessage ::= admissionReject :
{
requestSeqNum 36784
rejectReason calledPartyNotRegistered : NULL
}

debug gatekeeper main 10 – successful call

This debug is an extract from the output of the debug gatekeeper main 10 command and shows a successful call.

GK#show debug
gk main debug level = 10
H.225: H.225 ASN1 Messages debugging is on

!— The four-digit called number 1003 does not match with the three-dot wildcard
!— for localzone2 noted earlier. Instead, it matches with the less-specific
!— asterisk wildcard for localzone1.

Feb 19 16:52:19: rassrv_get_addrinfo(1003): Tech-prefix match failed.
Feb 19 16:52:19: rassrv_get_addrinfo(1003): Matched zone prefix 1 and remainder 003
Feb 19 16:52:19: No tech prefix
Feb 19 16:52:19: Alias not found

!— The gatekeeper finds a default technology prefix (of #1) since the 5350
!— TGWs register with this prefix as per the show gatekeeper gw-type-prefix command.

Feb 19 16:52:19: Technology GW selected

Solution

When you specify wildcard digits within a zone prefix, avoid using dots where possible. Instead, use the less-specific asterisk wildcard. You can also avoid the problem when you observe these rules:

If the dial-plan is consistent, you can use a configuration with only dots (or using only asterisks).
If there is an overlap in the dial-plan, it is best to stick to using configurations with asterisks.
If there is overlap in the dial-plan, and a configuration with only asterisks is not suitable, study the gatekeeper’s default behavior of prefix guessing (deduce and prepend the local area code) before you configure the gatekeeper.

gatekeeper
zone local localzone1 dns.au 10.1.1.228
zone local localzone2 dns.au
no zone subnet localzone1 default enable
zone subnet localzone1 10.1.1.240/28 enable
no zone subnet localzone2 default enable
zone subnet localzone2 10.99.0.0/16 enable
zone prefix localzone1 0*
zone prefix localzone1 1*
zone prefix localzone1 6*
zone prefix localzone1 8*
zone prefix localzone2 9999931..
Zone prefix localzone2 9999932..
Zone prefix localzone2 9999933..
Zone prefix localzone2 9999934..
Zone prefix localzone2 9999935..
Zone prefix localzone2 9999936..
Zone prefix localzone2 9999937..
Zone prefix localzone2 9999938..
Zone prefix localzone2 9999939..
Zone prefix localzone2 999994...
zone prefix localzone2 999995...
zone prefix localzone1 9*
accounting vsa
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
lrq reject-unknown-prefix
no use-proxy localzone2 default inbound-to terminal
no use-proxy localzone2 default outbound-from terminal
no shutgatekeeper zone local localzone1 dns.au 10.1.1.228 zone local localzone2 dns.au no zone subnet localzone1 default enable zone subnet localzone1 10.1.1.240/28 enable no zone subnet localzone2 default enable zone subnet localzone2 10.99.0.0/16 enable zone prefix localzone1 0* zone prefix localzone1 1* zone prefix localzone1 6* zone prefix localzone1 8* zone prefix localzone2 9999931.. Zone prefix localzone2 9999932.. Zone prefix localzone2 9999933.. Zone prefix localzone2 9999934.. Zone prefix localzone2 9999935.. Zone prefix localzone2 9999936.. Zone prefix localzone2 9999937.. Zone prefix localzone2 9999938.. Zone prefix localzone2 9999939.. Zone prefix localzone2 999994... zone prefix localzone2 999995... zone prefix localzone1 9* accounting vsa gw-type-prefix 1#* default-technology arq reject-unknown-prefix lrq reject-unknown-prefix no use-proxy localzone2 default inbound-to terminal no use-proxy localzone2 default outbound-from terminal no shutdown endpoint ttl 60down
endpoint ttl 60