IMPLEMENTING GATEKEEPERS WITH HOP-OFF TECH-PREFIX

March 1, 2009

In the course of my CCIE studies, I’ve found the “Gatekeeper Address Resolution on ARQ” chart extremely useful.
Having a good understanding of the call-flow displayed the chart is key to understanding the debug gatekeeper main 10 and how the gatekeeper logically looks through configured parameters to decide how a call will be routed.

The chart (shown below) should be available in the CCIE Voice Lab exam. It can be found on Page 10-40 (pg 350 figure 10-14) in the CCM 4.1 SRND, which we’ve been told would be available in the lab.

gk-address-resolution-for-arq

 

gk-address-resolution-on-arq_1

 

Now back to the Hop-off Tech Prefix.
While there are many ways to route calls on a gatekeeper, we may need to use the Hop-off Tech-prefix configuration scenario in the lab if we’re specifically asked to do that, or if we’re instructed not to use the following:

 – Tech prefix
 – Default gw-type-prefix
 – E.164 Aliases (including Alias Static commands for CCM numbers)
 – Zone Prefix

Looking at the chart, we’ll need to match Step 1. Though it’s typically used to route calls to Remote Zones via a Location Request (LRQ), the gatekeeper can also generate an ACF at this stage if the Hop-off points to a Local Zone.

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 (on Call Manager) 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.

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: CCM_GKCT_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

 
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:

Navigate to the CCM Service Parameters and do a search for 1720. You’ll find the section under Clusterwide Parameters (Device – H323).
Change the name from None to the name of your trunk. In my case, my trunk is called CCM_GKCT.
Once this is done, you’ll notice that the port number for your CCM trunk would now be 1720 after you reset it.

 
ccm_srvc_param_gkct_1720

 

We would now need to type in 3 commands to cater for the prefixes in HQ, BR1 and BR2.
gatekeeper
 zone local gk-zone1 myccielab.com 172.16.40.254
 gw-type-prefix 2* hopoff gk-zone1 gw ipaddr 10.10.50.103 1720
 gw-type-prefix 3* hopoff gk-zone1 gw ipaddr 10.10.50.103 1720
 gw-type-prefix 4* hopoff gk-zone1 gw ipaddr 172.16.30.254 1720
 no shutdown

 

Depending on whether we’ve been instructed to provide redundancy, we may need to include the secondary call-processing engine in the command for HQ and BR1 prefixes.
I’ve only got one call-manager running in my home lab, but here’s how you’ll configure it with two call-managers (assuming your second call-manager IP Address is 10.10.50.104)

 
 gw-type-prefix 2* hopoff gk-zone1 gw ipaddr 10.10.50.103 1720 gw ipaddr 10.10.50.104 1720
 gw-type-prefix 3* hopoff gk-zone1 gw ipaddr 10.10.50.103 1720 gw ipaddr 10.10.50.104 1720

 

You can verify your configuration by using the show gatekeeper gw-type-prefix command (or by making calls ;-))

 

GK-RTR(config-gk)#do sh gatekeeper gw-type-prefix                         
GATEWAY TYPE PREFIX TABLE
=========================
Prefix: 2*    (Hopoff zone gk-zone1)
  Statically-configured gateways (not necessarily currently registered):
    10.10.50.103:1720
  Zone gk-zone1 master gateway list:
    10.10.50.103:1720 CCM_GKCT_1

Prefix: 3*    (Hopoff zone gk-zone1)
  Statically-configured gateways (not necessarily currently registered):
    10.10.50.103:1720
  Zone gk-zone1 master gateway list:
    10.10.50.103:1720 CCM_GKCT_1

Prefix: 4*    (Hopoff zone gk-zone1)
  Statically-configured gateways (not necessarily currently registered):
    172.16.30.254:1720
  Zone gk-zone1 master gateway list:
    172.16.30.254:1720 CME_Trunk

 

PS: I’ve assumed your CME side has the following configuration:

dial-peer voice 1000 voip
 destination-pattern [23]…$
 session target ras
 incoming called-number .

 

Now, that’s a long post!!!!!


H.323 GATEKEEPERS

February 26, 2009

H.323 GATEKEEPERS

Gatekeepers are interesting devices that can be used for a variety of purposes within our Dial-Plans.
Some mandatory gatekeeper functions include Address Translation, Bandwidth Control and Zone Management.
One thing to note is that gatekeepers do NOTget involved with Codec Negotiation and any form of Digit Manipulation.

According to IP Expert instructor, Mark Snow “most students I’ve taught have the biggest problems with H323 Gatekeepers and……..“.

This statement is so true, considering that there are thousands of Call Manager deployments out there that don’t use gatekeepers.
I’ve been quite fortunate to work on an account that simply cannot function without gatekeepers because of the sheer amount of intra-cluster and inter-cluster communications spanning the entire globe.

I plan to dedicate a couple of blog-posts to this monstrous component of any large-scale dial-plan deployment.