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.
