Gatekeeper concept help

Answered Question
Aug 25th, 2008

I understand the purpose of the gatekeepers and the call hand offs between them, etc. What Im looking for is some real world scenarios and how they would work.

Im working on a design that involves six gatekeepers world wide. There will be (6) Callmanager clusters. Im not overly worried about CUCM. i will basically have an access code that send calls to their local designated Gatekeepers.

6 access code to the H323 trunk to the Gatekeeper.

Users will then dial the (3) digit site code and (4) digit extension.

Im assuming the GK will pick up 7 digit number and route to the appropriate GK by zones, etc.

The Gatekeepers are doing the CAC and not CUCM in this design.

Basically, if I have (6) gatekeepers and 6 clusters , calls between the clusters go through the GKs. The GKs hand off the calls to the the CUCM. The CUCM routes to the appropiate MGCP SRST site.

Would this be a correct statement, or do I have something turned around in this "high level" overview?


I have this problem too.
0 votes
Correct Answer by Marwan ALshawi about 8 years 3 months ago

about it CAC u can do it diffrent ways

but do it simple way as u have multiple GKs

on ur local GK make the CAC base on ur zone and every other zone or all other zones

also u can limit the amount of bandwidth for each call based on ur codec

good luck

if helpful Rate

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (6 ratings)
Marwan ALshawi Mon, 08/25/2008 - 16:16

hi Tommer

the proposed design u have mentioned very good and very right

u can make a GK for each site (zone) and based on the 3 digits ( zone prefixes) the call will be routed to the corsponding GK

and that GK will send the call to the CUCM at that site and so on

however there is other prespectives u might take it into ur consididration first high avalbilty and redunduncy

u might need to use GK clusturing or GK with HSRP so each group of sites will be handeled by on VIP witch represnet atleast two GK

or u can use a method for high scaleablity know as directory GK instead of make it fully meshed ur topology u just forward the calls from each site GK to the Directory GK and that DGK will handel the call (where to send it)

have a look at the following link

good luck

please, if helpful rate

Tommer Catlin Mon, 08/25/2008 - 20:35

Thanks much for your post! Yeah, I read about the clustering of gateways, Im not sure I can depending on the bandwidth. I would rather have a GK Directory in the Cloud that directs traffic.

One more question, In my CUCM cluster, Im really only concerned with the access code and RPs to the h323 GK correct? I do not need to worry about every other site within CUCM for CAC... just hand the call of to the local GK and let it handle it correct?

I was trying to figure out in CUCM what I need to configure. I have never used the GK in CUCM like gateways. I have only used RPs to H323 gateways (or GKs). So my thought was to build RPs patterns to the local GK and hand the call off.

So example:

Site A Site Code 400

Site B Site Code 500

Site C Site Code 600

Site A dials Site B.... 500xxxx.

RP in local CUCM cluster is 500XXXX to H323 GK gateway.

Call is handed to Gatekeeper, Gatekeeper finds the Zone B where Site Code 500 is and hands it the next Gatekeeper. Gatekeeper for Site B hands the call to CUCM h245 and CUCM connects the incoming call.

My only concern would CAC, but that would be handled in the GKs anyways correct?

Thanks again for your comments. I really appreciate it!!

Correct Answer
Marwan ALshawi Tue, 08/26/2008 - 00:27

about it CAC u can do it diffrent ways

but do it simple way as u have multiple GKs

on ur local GK make the CAC base on ur zone and every other zone or all other zones

also u can limit the amount of bandwidth for each call based on ur codec

good luck

if helpful Rate

Tommer Catlin Tue, 12/02/2008 - 21:00

Hey buddy, quick question on the GK clustering. I have (2) GKs and I want to cluster them for redundancy, I cant seem to figure how it is supposed to work.

Basically each GK has cluster associated to it.

GK1 CUCM Cluster 1

GK2 CUCM Cluster 2

GK1 has (5) H323 Gatways registered to it (and cucm)

GK2 has (5) H323 gateways registered it as well.

If GK1 goes down, how do the H323 gateways know to use GK2 for routing, etc?


Marwan ALshawi Wed, 12/03/2008 - 02:01

When the cluster is first established, the gatekeeper opens and maintains a TCP connection to the other members of the cluster (the alternate gatekeepers). The gatekeeper announces its presence by sending a GRQ message containing nonstandard data; then it flags it as an announcement. The announcement also carries information about bandwidth utilization for a zone. This allows the alternate gatekeepers to manage the bandwidth for a zone even though they are separate devices.

GUP GRQ messages can be one of the following formats: announcementIndication, announcementReject, registrationIndication, unregistrationIndication, or resourceIndication.

GUP announcements are sent every 30 seconds by default. Cluster members assume that a gatekeeper has failed if nothing is heard from that gatekeeper for six consecutive announcement periods or if the TCP connection is lost.

When a gateway registers/unregisters with a gatekeeper in a cluster, that gatekeeper uses the registrationIndication/ unregistrationIndication message to update all other gatekeepers in that cluster.

If a gateway reports a resource change using an RAI message to a gatekeeper in a cluster, that gatekeeper reports the change to all alternate gatekeepers in the cluster using the GUP resourceIndication message.

GUP messages allow all the gatekeepers in a cluster to have knowledge about the registration status, bandwidth, active calls, and resource status for every gateway in the zone

hope this helps

iptuser55 Wed, 12/03/2008 - 08:19

Is there anything you need to configure on the Alternative GK apart from the Alise names of each other to start the GUP exchange? Terminology wish is GUP the same as Alternative clustering? many thanks

Tommer Catlin Fri, 12/05/2008 - 13:37

here is what I did:


added in the following statements:

Zone_alt (zone ID and alt for backup identification)

Zone prefix zone_alt xxx* (zone prefix for the zone_alt)


zone cluster local zone_cluster zonename

element zone_alt IP address of GKB 1719

Do the same on GKB, but reverse it all.

Work great!

Marwan ALshawi Mon, 12/08/2008 - 02:41

Configuring gatekeeper clusters can be confusing. Each local zone is represented by a different name on each cluster member. It can help clarify if you think of a zone as having a "base name" and then an alias on the other cluster members. The gateways use the "base name" when they register to the gatekeeper zone.

For example, if a local zone base name is boise, and it is in a cluster with two alternate gatekeepers, you could use the names boise_gka and boise_gkb for the alternates. This could represent gatekeeper alternative A (gka) and gatekeeper alternative B (gkb) for the zone. In reality, the actual names used on the alternates can be anything as long as they are unique. Developing a naming scheme that has some meaning can help you to keep everything straight as you build the configuration.

Zone configuration is done in gatekeeper configuration mode. When you are configuring the gatekeeper, every local zone is listed with a zone local command and a zone cluster command. The zone local command defines the zone as it is known to the local gatekeeper. The zone cluster command identifies aliases for the zone and the IP addresses of the alternate gatekeepers that can process requests for that zone. The command format is zone cluster local cluster-name zone-name. The zone-name must match what is defined in the zone local statement. Aliases for the zones (names of the zones as they are known on alternate gatekeepers) are defined using the element zone-alias ip-address command. The IP address is that of the gatekeeper interface on the alternate gatekeeper where that zone alias is defined.

You might also find occasions where you want one gatekeeper to be primary for some zones and other gatekeepers as primary for other zones. This might be because of network topology, proximity, or other factors.

The following shows how a simple cluster can be built, based on the sample network. The sample network contains three local zones: ny, boise, and miami. GK_A is the primary gatekeeper for zone miami, and it is the alternate for ny and boise. GK_B is the primary for zones ny and boise, and it is the alternate for zone miami

source cisco press


This Discussion