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
