Cisco Voice Guru

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

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]

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.

Read the rest of this entry »

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

RAI Concept:

Resource Allocation Indication allows gatekeepers to make informed call routing decisions based on a predefined threshold levels for DS0 channels and DSP channels.  The gateway will report its utilization statistics via H.225 RAI to the H.323 gatekeeeper.  When a monitored resource falls below the configured threshold, the gateway will inform the gatekeeper that it is almost out of resources.

H.323 version 2 and 3 support yes/no resource availability information.  H.323 version 4 introduced call capacity.

How RAI Works:

Resource reporting thresholds are configured by using the resource threshold command under the gateway CLI. The upper and lower thresholds are separately configurable to prevent the gateway from operating sporadically due to the availability or lack of resources.  The default for “high” and “low” values is 90.

resource threshold [all] [high percentage-value] [low percentage-value]

Utilization is calculated taking with the following formula:
Accessible channels = Inuse + Free
Utilization = Inuse / Acceptable

For example, assume you have four T1 PRIs: two PRIs for incoming calls, two for outgoing. You have busied out 44 timeslots of the outgoing timeslots and you have one call on one of the outgoing timeslots. You will have:

• Total = 92 (23 B channels x 4 T1 PRIs)
• Addressable = 46 (23 B channels x 2 T1 PRIs)
• Disabled = 44
• Inuse = 1
• Free = 1

The utilization = 1/(1+1)= 50 %.   Therefore, if the configured high threshold is 90%, the Gateway still accepts calls.

Additional Insights:

• The above calculations only took the DS0 resources into consideration. However, the DSP resources are monitored and calculated in the same way. Also, depending on which resource (DSP or DS0) reaches the low or high threshold first, the gateway sends the RAI messages.
• No configuration is needed on the gatekeeper to activate the RAI.
• An RAI message, like any other RAS message, is UDP. Once the gateway sends an RAI message to the gatekeeper, it starts a three second timer. If the timer expires before it receives the RAC, the gateway tries to send the RAI again nine more times. Then, it gives up until the resource availability status changes again.
• RAI is useful if you want to give priority to a certain gateway. Also, once the threshold is reached, then you route the traffic to other gateways.
• With the command lrq reject-resource-low, the gatekeeper rejects the inter-zone call if all gateways in that zone are marked as almost-out-of-resources. This command is integrated in Cisco IOS Software Release 12.1(3a)XI6. If you do not use this command, the gatekeeper does not reject any calls from other zones when all gateways in that zone are marked as out of resources.

H.323 Gateway Configuration

interface Ethernet0
ip address 172.16.13.45 255.255.255.224load-interval 30
h323-gateway voip interface
h323-gateway voip id cisco_2 ipaddr 172.16.13.42 1718
h323-gateway voip h323-id 5300-3
h323-gateway voip tech-prefix 2#
!
gateway
resource threshold high 70 low 60

Verification

show gateway
show pool
show call resource voice stat
show call resource voice threshold
show gatekeeper gw-type-prefix
show gatekeeper endpoint

Debugs

Turn on debug ras and debug h225 asn1 if you think that the gateway is not sending the proper RAI message or the gatekeeper is not sending the RAC message.