Troubleshooting Gatekeepers

If it looks like everything is configured properly and you are still having trouble placing calls, some tools are available to assist with troubleshooting. Some of the show commands already mentioned are quite useful. Several debug commands can also help you figure out the problem.

Of course, the first thing you need to do is make sure that the issue involves a gatekeeper call, rather than a more basic issue. Make sure all the trunks are operating cleanly, that dial peers are configured correctly, and that all the gateways and the gatekeeper are reachable on the IP network.

Registration Issues

If all the gatekeepers, trunks, dial peers, and gateways look okay, be sure the gateways are registered with the gatekeeper. You can do this by using the show gatekeeper endpoints command. If the gateway is not registered with the gatekeeper, you can find out more information using the debug h225 asn1 command on the gateway. Example 17-9 shows the trace output for a successful gatekeeper discovery.

[View full width]

Miami#debug h225 asn1 value RasMessage ::= gatekeeperRequest : { requestSeqNum 7401 protocolIdentifier { 0 0 8 2250 0 4 } rasAddress ipAddress : { ip '0A0C0102'H ## IP Address of gateway in hex (10.12.1.2) port 55895 } endpointType { vendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } } gateway { protocol { voice : { supportedPrefixes { { prefix dialedDigits : "1#" ## Technology Prefix } } }, h323 : { supportedPrefixes { } } } } mc FALSE undefinedNode FALSE } gatekeeperIdentifier {"miami"} endpointAlias { h323-ID : {"[e-mail]"} ## H.323 ID of the gateway } } value RasMessage ::= gatekeeperConfirm : { requestSeqNum 7401 protocolIdentifier { 0 0 8 2250 0 4 } gatekeeperIdentifier {"miami"} ## Local Zone Name the gateway will register to. rasAddress ipAddress : { ip '0A646401'H ## IP Address of Discovered Gatekeeper (10. 100.100.1) port 1719 } }  

If any of the parameters do not match what you expect, or if you receive no response, recheck the configuration on both sides to make sure a mismatch has not occurred. Example 17-10 shows a registration failure. Looking at the trace output, you can see that the gatekeeper zone name "boise" is misspelled. The gatekeeper reject reason "TerminalExcluded" in this case means that no zone name matched the registration request.

! Unnecessary Output Deleted
value RasMessage ::= gatekeeperRequest : 
 {
 requestSeqNum 6155
 protocolIdentifier { 0 0 8 2250 0 4 }
 rasAddress ipAddress :
 {
 ip '0A0105C8'H
 port 49785
 }
 endpointType
 {
 vendor
 }
 gateway
 {
 protocol
 {
 voice :
 {
 supportedPrefixes
 {

 {
 prefix dialedDigits : "1#"
 }
 }
 gatekeeperIdentifier {"boisy"} 
 endpointAlias
 {
 dialedDigits : "0100",
 dialedDigits : "0101",
 h323-ID : {"[e-mail]"}
 }
 }

value RasMessage ::= gatekeeperReject: 
 {
 requestSeqNum 6155
 protocolIdentifier { 0 0 8 2250 0 4 }
  rejectReason terminalExcluded : NULL
 }

 

 

Call Routing Issues

The debug gatekeeper main 5 trace command is a useful, but undocumented, tool that can help identify call routing problems in the gatekeeper. The output of this command actually shows the decision tree steps that the gatekeeper takes as it processes the ARQ. Example 17-11 shows two examples of this trace output. The first shows a successfully completed call; the second shows one that failed to find a matching prefix.

[View full width]

CALL TO 911 SUCCESSFULLY HANDLED *Aug 6 07:11:16.347: gk_rassrv_arq: arqp=0x840DD720, crv=0x7, answerCall=0 *Aug 6 07:11:16.347: gk_dns_query: No Name servers *Aug 6 07:11:16.347: rassrv_get_addrinfo: (911) Tech-prefix match failed. *Aug 6 07:11:16.347: rassrv_get_addrinfo: (911) Matched zone prefix 911 and remainder *Aug 6 07:11:16.347: rassrv_arq_select_viazone: about to check the source side, rc_zonep=0x848CB0A8 *Aug 6 07:11:16.347: rassrv_arq_select_viazone: matched zone is boise , and z_invianamelen=0 *Aug 6 07:11:16.347: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x848CB300 *Aug 6 07:11:16.351: rassrv_arq_select_viazone: matched zone is miami , and z_outvianamelen=0 *Aug 6 07:11:16.351: gk_zone_get_proxy_usage: local zone= miami, remote zone= boise, call direction= 0, eptype= 2050 be_entry= 0 *Aug 6 07:11:16.351: gk_zone_get_proxy_usage: returns proxied = 0 *Aug 6 07:11:16.351: gk_gw_select_px: Source and destination endpoints in different local zones *Aug 6 07:11:16.351: gk_zone_get_proxy_usage: local zone= boise, remote zone= miami, call direction= 1, eptype= 2050 be_entry= 0 *Aug 6 07:11:16.351: gk_zone_get_proxy_usage: returns proxied = 0 *Aug 6 07:11:16.511: gk_rassrv_arq: arqp=0x841FCA30, crv=0x6, answerCall=1 *Aug 6 07:11:16.591: gk_rassrv_irr: irrp=0x840DD720, from 10.12.1.2: 50461 *Aug 6 07:11:17.099: gk_rassrv_irr: irrp=0x841FCF18, from 10.1.5.200: 55005l ARQ FAILED TO MATCH ZONE CALL REJECTED *Aug 6 07:17:19.731: gk_rassrv_arq: arqp=0x841FC1E0, crv=0xA, answerCall=0 *Aug 6 07:17:19.731: gk_dns_query: No Name servers *Aug 6 07:17:19.731: rassrv_get_addrinfo: (91201555) Tech-prefix match failed. *Aug 6 07:17:19.731: rassrv_get_addrinfo: (91201555) unresolved zone prefix  

You can also use the debug h225 asn1 command to see a great deal of detail about the RAS message. Although the output of this trace is verbose, it can provide invaluable information when you are trying to determine the reason that a call is not going through. The called and calling number, the bandwidth requested, and the gateway H.323 ID are all fields that you can easily see in the trace.

Example 17-12 shows the output of a call that failed because the called number was not registered. This indicates a misdialed number, an incorrectly coded dial peer, or an unregistered destination gateway.

ARQ TO GATEKEEPER

value RasMessage ::= admissionRequest :
 {
 requestSeqNum 81
 callType pointToPoint : NULL
 callModel direct : NULL
 endpointIdentifier {"83B7042800000001"}
 destinationInfo
 {
 dialedDigits : "91201555" 
 }
 srcInfo
 {
 dialedDigits : "2085550100", 
 h323-ID : {"[e-mail]"} 
 }
 bandWidth 160 
 callReferenceValue 11
 nonStandardData
 {
 nonStandardIdentifier h221NonStandard :
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 data '80000010290A1046585320302F322F3030002D49...'H
 }
 conferenceID 'D13AF02AAA2711DA802CC10D3BDE93AE'H
 activeMC FALSE
 answerCall FALSE
 canMapAlias TRUE
 callIdentifier
 {
 guid 'D13AF02AAA2711DA802EC10D3BDE93AE'H
 }
 willSupplyUUIEs FALSE
 }

 

ARJ FROM GATEKEEPER

value RasMessage ::= admissionReject :
 {
 requestSeqNum 81
 rejectReason calledPartyNotRegistered : NULL
 nonStandardData
 {
 nonStandardIdentifier h221NonStandard :
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 data '80400160'H
 }
 }

 

If the trace of the ARQ looks normal and the calls are still not being completed, the next step is to look at the call as it is processed in the destination gateway. Verify that the correct dial peers are being matched, the correct information is being sent to the PSTN or PBX on the outbound trunk, and so on. It is important to have an understanding of the end-to-end call flow, and to take a systematic approach to troubleshooting each step as the call progresses through the network components.

CallManager and Gatekeepers