Archive for the ‘H.225’ tag
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.
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.
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]
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
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.
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
Voice Capacity Max.= Avail.= Current.= 0
172.16.30.254 1720 172.16.30.254 57634 gk-zone1 VOIP-GW
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