Cisco Voice Guru

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.

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

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

The determining factor for whether a gateway registers with a TYPE of VOIP-GW or H323-GW relies entirely on the “allow-connections” commands entered under “voice service voip.” Essentially, if your gateway is functioning as an IP-to-IP gateway, it will display H323-GW.

The commands that make or break this:

voice service voip
allow-connections h t h
allow-connections h t s
allow-connections s t h
allow-connections s t s

After adding or removing these, make sure to bounce your gateway registration with the gatekeeper using “no gateway” and “gateway.”

I just verified this. Here is a snapshot without the commands listed above:

HQ-RTR#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
————— —– ————— —– ——— —- —–
10.10.202.1 1720 10.10.202.1 58978 Spain VOIP-GW
H323-ID: BR2-RTR
Voice Capacity Max.= Avail.= Current.= 0

After adding the commands listed above:

HQ-RTR#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
————— —– ————— —– ——— —- —–
10.10.202.1 1720 10.10.202.1 50555 Spain H323-GW
H323-ID: BR2-RTR
Voice Capacity Max.= Avail.= Current.= 0

According to Bellcore and ANSI specifications, in-band progress tones and announcements are required for PSTN services and for ISDN speech and 3.1-kHz voice services. In order to guarantee that the necessary in-band tones are generated when required (and at the right switch), Cisco H.323 gateways must ensure that Progress Indicators or PIs are carried end-to-end in called signaling messages between the calling and called parties. The PI is an IE that signals when in-band tones and announcements are available. The PI is configured by the "progress_ind" command. Below is a list of PIs that can be configured on a Cisco H.323 gateway:

Configurable Progress Indicator Values for H.323 Gateways

• PI=0 No progress indicator is included. Message type: Setup
• PI=1 Call is not end-to-end ISDN; further call progress information may be available in-band. Message type: Alert, setup, progress, connect
• PI=2 Destination address is non-ISDN Message type: Alert, progress, connect
• PI=3 Origination address is non-ISDN Message type: Setup
• PI=8 In-band information or appropriate pattern is now available Message type: Alert, progress, connect

Read the rest of this entry »

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.

Read the rest of this entry »

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]

Below are the following destination-pattern operators that can be used in IOS dial-peers for voice:

Standard Operators

• Asterisk (*) and pound sign (#)—Keys that appear on standard touchtone dial pads.
• Brackets ([ ])—Range of digits. Digits (0 to 9) are enclosed in brackets. Similar to a regular expression rule.
• Parentheses (( ))—Define specific pattern. Same as the regular expression rule—for example, 408(555). Use parentheses in conjunction with symbols ? or %.
• Period (.)—Match to any entered digit (used as a wildcard).
• Comma (,)—Pause between digits.

“Repeating” Operators

• Percent sign (%)—The previous digit or pattern zero or multiple times, similar to wildcard usage in the regular expression.
• Question mark (?)—The previous digit occurred zero or one time.

Other Operators

• Circumflex (^)—Match to the beginning of the string.
• Dollar sign ($)—Match to the null string at the end of the input string.
• Backslash (\)—Is followed by a single character matching that character or used with a single  character having no other significance (matching that character).
• T—Control character indicating that the destination-pattern value is a variable-length dial string.

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.

Read the rest of this entry »

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

Read the rest of this entry »