Understanding Gatekeepers, Gatekeeper Call Routing & CUBE - Part 1/3

So what is a Gatekeeper and what do you basically need Gatekeepers for?, well those are some of the most primitive questions I'd presume most of us would pose before even trying to disect the concept of GK Call Routing & CUBE..... 

For the first part of the question, 15 years back I'd answer: A Gatekepeer is basically someone (most probably security personnel) who looks after the big black gate of your building (that's if your building has a gate...lol..) admitting people who request permission to enter the building upon verifying their identity and whether the individual they actually intend to meet is registered in the building records as a valid tenant/owner... then the gatekeeper either grants them or rejects them admission to the building....... simple isn't it!!! 

.... well that is exactly what the Gatekepeer in a VOIP network does as part of it's functionality (CAC - Call Admission Control). 

So to translate the above in terms of Cisco VOIP Networks: 

A Gatekeeper maintains a record/table of all registered endpoints (an endpoint here is nothing but a cisco call processing agent, either cucm or cme) by their name (h323-id, this is defined on the end-point), their tech-prefix (can be defined on the end-point or the gatekeeper)... there are a few more parameters that we will talk about ahead..... 

Now, why do you need Gatekeepers? 

Let's assume you have a voip network of 3 CME Devices (each CME Device has a phone registered to it, Ph1, PH2 & PH3), now if PH1 in CME1 wants to call PH2 in CME 2 then you'd have an outgoing dial-peer on CME1 to send the call to CME2 and an incoming dial-peer on CME2 to receive that call and vice-versa for the call in the opposite direction.... now again if PH1 wants to make a call to PH3 registered to CME3 then again two dial-peers (you can combine the incoming dial-peer on each CME to be a generic one to match all incoming calls but you'll anyway have a unique outgoing dial-peer for each outgoing call to a different number....), so if you have 100 CME devices instead of 3 then you would need 100 or more outgoing dial-peers with different session-target ipv4's pointing to different CME devices...and this would be done on each CME device in order for phones in each CME device to be able to call the phones registered to all the 100 other CME Devices.... so it gets tedious, messy, hard to maintain with each growing new CME device, hard to troubleshoot if something goes wrong, etc.... 

So when you have a large number of sites/cme devices/cucm devices/endpoints that you have to route calls between it gets easier to have some device sit in the middle and accept calls from every other device on the VOIP Network and then based on some call routing algorithm/flow-chart/decision making... route those calls to the right endpoint/call-processing agent/cme/cucm..., this device sitting in the middle making the call routing decisions is the Gatekeeper and this is the second function of the gatekeeper "Dial-Plan Management/Simplification".... this function of the gatekeeper simplifies the call routing process by reducing the number of voip dial-peers at each endpoint and eases the troubleshooting process with the gatekeeper mainly having all the call routing configuration in a voip network now... 

Further more any changes in the Call Routing over the vOIP Network would just require Adds, Moves, Changes on the Gatekeeper only and not on the numerous end points....so with the gatekeeper in the middle of the voip-network (accepting and forwarding calls) all you got to do is register each end point to the Gatekeeper and have an/one outgoing dial-peer sending the call to Gatekeeper... 

something like: 

dial-peer voice voip 10 
destination-pattern .T 
session-targer ras (ras stands for "registration", "admission", "status" and it indicates that the call needs to be sent to the gatekpeer the endpoint is registered with) 

More on the configuration part in the next post...