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"} |
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 : {"boise@cisco.com"} } } 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, |
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 : {"boise@cisco.com"} } 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
|