Jan
15

People constantly have troubles understanding the Gatekeeper-based call routing model. In this post, we are going to discuss the basic call-routing logic. Reader is assumed to understand the most fundamental gatekeeper configuration commands.

Basic Concepts

The first concept is the gatekeeper technology-prefix, which is the core of the gatekeeper dynamic call-routing process. Look at the tech-prefix as a special label used to group together a set of VoIP gateways. The gateways may register their technology prefixes with the gatekeeper dynamically, or you can map the prefixes to the VoIP gateways statically. The gatekeeper looks at the gateways registered under the same tech-prefix to be members of a single “gateway pool”. Now, recall that tech-prefix is just a part of the dialed number. Whether the called number prefix is actually a technology prefix, is decided by the gatekeeper, when it matches the dialed number against the database of the local registered/configured prefixes. There is nothing in the dialed number itself, that designates the part of the dialer string as a technology prefix.

A special instance of tech-prefix is the default-techology prefix. When you have one or more tech-prefixes registered by gateways or configured statically, you can designate one of them as “default”. The gatekeeper will “route” the incoming call to this prefix if it cannot match the incoming call against any registered/configured tech-prefixes. Notice that this happens even though the dialed number prefix does not match any of the local technology prefixes.

The next concept is zone. A zone is a collection of destination numbers (dialing prefixes). Zones could be either local – serviced by this gatekeeper – or remote – serviced by remote gatekeepers. Zones are used for two purposes – admission control and call routing. For every incoming call, the gatekeeper need to determine the zones that the calling and called numbers belong to, in order to perform admission control. Note one important detail here – every gateway registers within a particular zone.

The last concept is zone bandwidth. This is a special attribute that you assign to a zone. When a call is placed between two zones or within the same zone, the gatekeeper first tries to reduce the current zone bandwidth by the bandwidth of the call. If source/target zones both have enough bandwidth, the call is admitted. This constitutes the core of GK-based admission control procedure.

Call Routing Process

Here is a simplified step-by-step description of the call-routing process. Note that it may not strictly follow the actual logic, but rather is outlined in the easy to understand manner.

Step 1:
A gateway sends ARQ to the gatekeeper, requesting admission for given calling and called numbers. The gatekeeper first determines the source zone, as where the calling gateways is registered. Gateways normally register within a zone, so there is no problem finding the source zone.

Step 2:
The gatekeeper tries to match the called number against the list of the registered or manually configured tech-prefixes.

a) If a match is found, the gatekeeper stores the matched tech-prefix.
b) The gatekeeper tries to match the called number with tech-prefix stripped against the list of all zone prefixes. (If the tech prefix was not found , the gatekeeper tries to match the original dialed string against the zone prefix list).

Step 3:
If there is a match found while looking up the zone prefix list, the gatekeeper has found the target zone. If there is no zone-prefix match, then the gatekeeper assumes the target zone to be the source zone, found in Step 1.

Step 4:
At this point gatekeeper attempts to perform a routing decision, based on the information collected: tech-prefix, zone-prefix and target zone.

a) If the target zone is remote-zone, then hop the call off to the remote gatekeeper, sending LRQ. The local GK no longer cares for this call. The call is hopped off as it was received, with unmodified called and calling numbers (including the tech-prefix). NOTE: This step does NOT require the called number to find a match within local tech-prefixes. Thus, if there is a tech-prefix in the called number, it is considered be the part of the number and matched against the zone prefixes.
b) Otherwise, the gatekeeper attempts to route the call locally, based on the tech-prefix. The gatekeeper constructs a pool of the gateways registered under the matched tech-prefix.
b.1) Verify if there are gateways in this pool registered under the target zone (remember, the zone is selected based on dialed prefix!). Only these gateways constitute the set of possible targets. Thus the pool of availale gateways is constructed as intersection of the gateways in the target zone registered under the matched tech-prefix.
b.2) If the called number did not match any tech-prefix at Step 1 try to see if there is a default tech-prefix configured. If there is one, then select the gateways registered with this prefix under the target zone. Note, that this allows call routing without a technology prefix prepended to the dialed number.

Step 5:
At this point the gatekeeper has the set of target gateways to probe for the called number. The gatekeeper will attempt to route the call to each of this gateways in sequence, based their associated priorities as follows. Setting priorities allows for granular selection of gateways within a pool. Look at the following example.

gatekeeper
 zone prefix Z_HQ 1... gw-priority 10 GW_HQ_A
 zone prefix Z_HQ 1... gw-priority 9 GW_HQ_B
 gw-type-prefix 1# default-technology

Let’s assume that both GW_HQ_A and GW_HQ_B registered the same tech-prefix 1#, and the called number matches the zone prefix. When the gatkeeper tries to select the next gateway to handle the call, it picks up the one with the highest priority for the prefix. The default priority value is 5, and by setting the priority to zero you effectively exclude this gateway as being a potential target for this prefix. You may need this in situation where you have multiple gateways in the same zone sharing the same tech-prefix. Per default behavior, the gatekeeper simply tries the gateways in round-robin fashion based on the default priority value for every subsequent call attempt.

Step 6:
If there called number did not match any tech-prefix AND there is no default-tech prefix configured the gatekeeper tries to match the called number against the list of registered E.164 endpoints (terminals). If there is a match, the call is routed to the endpoint.

Step 7:
If the call is routable, the gatekeeper performs admission control procedure, based on the source/target zone bandwidth settings and the call bandwidth. If there is enough bandwidth, the call is admitted and the calling gateway receives the target IP address.

Example 1:
One local zone, one tech-prefix (1#), two gateways (GW_BR1, GW_BR2) in the pool.

R1:
gatekeeper
 zone local Z_ZONE cisco.com
 no shutdown

R2:
gateway
!
interface Loopback0
 ip address 177.10.254.2 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip id Z_ZONE ipaddr 177.10.254.1 1719
 h323-gateway voip h323-id GW_BR1
 h323-gateway voip bind srcaddr 177.10.254.2
 h323-gateway voip tech-prefix 1#
!
dial-peer voice 100 voip
 destination-pattern .T
 session target ras

R3:
gateway
!
interface Loopback0
 ip address 177.10.254.3 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip id Z_ZONE ipaddr 177.10.254.1
 h323-gateway voip h323-id GW_BR2
 h323-gateway voip bind srcaddr 177.10.254.3
 h323-gateway voip tech-prefix 1#
!
dial-peer voice 100 voip
 destination-pattern .T
 session target ras

Place a call from R3 (GW_BR2):

R1#debug gatek main 10

R3#debug h225 q931
H.225 Q931 IE Details debugging is on

R3#csim start 1000
csim: called number = 1000, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(13)
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0

As we can see, GW_BR2 did not even attempt to start a new call. The gatekeeper debugs reveal the following:

R1#
rassrv_get_addrinfo: (1000) Tech-prefix match failed.
rassrv_get_addrinfo: (1000) unresolved zone prefix, using source zone Z_ZONE
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4797D0D0
 rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_outvianamelen=0
rassrv_get_addrinfo: No tech prefix

rassrv_get_addrinfo: Alias not found

rassrv_get_addrinfo: (1000) unknown address and no default technology defined.

In this case we ended up with no tech-prefix, source zone=target zone=Z_ZONE.

Now place a call prepended by the tech-prefix:

R3#csim start 1#1000
csim err csimDisconnected recvd DISC cid(14) 

Q931 Message IE Decodes
Protocol Discriminator : 0x08
CRV Length             : 2
CRV Value              : 0x000E
Message Type           : 0x05: SETUP
[snip]

R1#
rassrv_get_addrinfo: (1#1000) Matched tech-prefix 1#
rassrv_get_addrinfo: (1#1000) unresolved zone prefix, using source zone Z_ZONE
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_outvianamelen=0
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1

As we can see, now the tech-prefix has matched, and the gatkeeper returns a gateway in ACF. GW_BR2 tries to place a call to the first gateway in sequence, as seen from Q931 debugging output. Every time you place another call, the gatekeeper will return a new gateway in sequence.

Example 2

Two local zones, two zone prefix, two tech-prefixes, two gateways.

R1:
gatekeeper
 zone local Z_BR1 cisco.com
 zone prefix Z_BR1 2...
 zone local Z_BR2 cisco.com
 zone prefix Z_BR2 3...
 no shutdown

R2:
gateway
!
interface Loopback0
 ip address 177.1.254.2 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip id Z_BR1 ipaddr 177.1.254.1 1719
 h323-gateway voip h323-id GW_BR1
 h323-gateway voip bind srcaddr 177.1.254.2
 h323-gateway voip tech-prefix 2#
!
dial-peer voice 100 voip
 destination-pattern .T
 session target ras

R3:
gateway
!
interface Loopback0
 ip address 177.1.254.3 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip id Z_BR2 ipaddr 177.1.254.1
 h323-gateway voip h323-id GW_BR2
 h323-gateway voip bind srcaddr 177.1.254.3
 h323-gateway voip tech-prefix 3#
!
dial-peer voice 100 voip
 destination-pattern .T
 session target ras

We run the same debugs as in the first example.

First, we try placing a call using the tech-prefix registered in Z_BR1 and calling the prefix in Z_BR2:

R3#csim start 3#2001
csim: called number = 3#2001, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(3)
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0

The call fails, since the gatekeeper selects the gateway with tech-prefix in Z_BR2 and with the zone prefix in Z_BR1. Here is the gatekeeper output:

R1#
rassrv_get_addrinfo: (3#2001) Matched tech-prefix 3#
rassrv_get_addrinfo: (3#2001) Matched zone prefix 2 and remainder 001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x469FCCC4
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_outvianamelen=0
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_get_addrinfo: (3#2001) tech-prefix gateway selection failed.

Now, if you use the tech-prefix 2#, the call will go just fine:

R1#
rassrv_get_addrinfo: (2#2001) Matched tech-prefix 2#
rassrv_get_addrinfo: (2#2001) Matched zone prefix 2 and remainder 001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x469FCCC4
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_outvianamelen=0

R3#csim start 2#2001
csim: called number = 2#2001, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(7)
  Q931 Message IE Decodes
Protocol Discriminator : 0x08
CRV Length             : 2
CRV Value              : 0x0007
Message Type           : 0x05: SETUP
 Bearer Capability: Length Of IE=3

Example 3

Two gatekeepers (R1 and R3); local and remote zone; two tech-prefixes; two gateways (R2 and R3);

R1:
gatekeeper
 zone local Z_BR1 cisco.com
 zone prefix Z_BR1 2...
 zone remote Z_BR2 cisco.com 177.1.254.3
 zone prefix Z_BR2 3*
 no shutdown

R2:
gateway
!
interface Loopback0
 ip address 177.1.254.2 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip id Z_BR1 ipaddr 177.1.254.1 1719
 h323-gateway voip h323-id GW_BR1
 h323-gateway voip bind srcaddr 177.1.254.2
 h323-gateway voip tech-prefix 2#
!
dial-peer voice 100 voip
 destination-pattern .T
 session target ras

R3:
gatekeeper
 zone local Z_BR2 cisco.com 177.1.254.3
 zone prefix Z_BR2 3...
 zone remote Z_BR1 cisco.com 177.1.254.1
 zone prefix Z_BR1 2*
 no shutdown
!
gateway
!
interface Loopback0
 ip address 177.1.254.3 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip id Z_BR2 ipaddr 177.1.254.3
 h323-gateway voip h323-id GW_BR2
 h323-gateway voip bind srcaddr 177.1.254.3
 h323-gateway voip tech-prefix 3#
!
dial-peer voice 100 voip
 destination-pattern .T
 session target ras

When we call 3#3001 from R2, the gateway first asks R1 – its gatekeeper. The gatkeeper could not match this call against any tech-prefix, but it matches against the remote zone prefix 3*. The call is then hopped off to R2.

R2#csim start 3#3001

R1#
rassrv_get_addrinfo: (3#3001) Tech-prefix match failed.
rassrv_get_addrinfo: (3#3001) Matched zone prefix 3 and remainder #3001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x469F7B38
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_outvianamelen=0
rassrv_get_addrinfo: No tech prefix

rassrv_get_addrinfo: Alias not found

rassrv_put_remote_zones_from_zone_list: zone Z_BR2
send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1
send_lrq: lrq array index 7, lap 476A807C
send_lrq: sent lrq - zonecount 1

Now LRQ reaches R3. This gatekeeper tries the usual call-routing procedure, matching the called number against the list of registered tech-prefixes. Then a match for the zone prefix is found in local zone. The gatekeeper only has to select the gateway from the pool.

R3#
gk_rassrv_lrq: (3#3001) Matched tech-prefix 3#
gk_rassrv_lrq: (3#3001) Matched zone-prefix 3
gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0
gk_rassrv_lrq: srcvia found gkname of source zone. looking up Z_BR1 in zone list
gk_rassrv_lrq: about to check the source side, src_zonep=0x673FC104
gk_rassrv_lrq: matched zone is Z_BR1
gk_rassrv_lrq      and z_invianamelen=0
gk_rassrv_lrq: about to check the destination side, zonep=0x650C63D0
gk_rassrv_lrq:matched zone is Z_BR2
gk_rassrv_lrq      and z_outvianamelen=0

Now try making a call to 2#3001. In this situation, R1 should block the call for the tech-prefix and the zone prefix are in different zones. However, this rule only works for local zone. When the zone prefix match in remote zone, the gatekeeper immediately hops the call off, even if the tech prefix is registered locally.

R1#
rassrv_get_addrinfo: (2#3001) Matched tech-prefix 2#
rassrv_get_addrinfo: (2#3001) Matched zone prefix 3 and remainder 001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x469F7B38
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_outvianamelen=0
rassrv_put_remote_zones_from_zone_list: zone Z_BR2
send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1
send_lrq: lrq array index 9, lap 476A810C
send_lrq: sent lrq - zonecount 1

R3#
gk_rassrv_lrq: (2#3001) Tech-prefix match failed.
gk_rassrv_lrq: (2#3001) Matched zone-prefix 2
gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0
gk_rassrv_lrq: srcvia found gkname of source zone. looking up Z_BR1 in zone list
gk_rassrv_lrq: about to check the source side, src_zonep=0x673FC104
gk_rassrv_lrq: matched zone is Z_BR1

The call still fails, since R3 can not match the called number against any local tech-prefix.

Summary

As we can see, the core of the gatekeeper call-routing is using tech-prefixes for gateway pooling and using zones and zone prefixes to partition the pools. We omitted some advanced details, such as RAI and hop-off tech-prefixes for clarify. However, the general process looks as described above.

Further Reading

Understanding Cisco IOS Gatekeeper Call Routing
VoIP with Gatekeeper
Basic Two Zone Cisco Gateway-to-Gatekeeper Configuration
Zone Prefix Processing with Dots Versus Asterisks

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

7 Responses to “Gatekeeper Call-Routing at a Glance”

 
  1. Nicholas says:

    Hi,

    Thanks a lot for this deep insight into gatekeepers,

    Please shed more light on gatekeeper integration on a callmanager(cluster) environment.

    I have a site which requires gatekeeper integration into a number of callmanager clusters.

    I have done some configurations on both the callmanagers and the gatekeeper,but somehow things dont seem to work as they should.

    Once again thank you.

  2. Abbas says:

    Thanks a lot for clear explanation on gatekeeper tech-prefix subject.

  3. CiscoSri says:

    Hi, This is really amazing, the document has given me a more deeper understanding of Gatekeeper Call Routing.

  4. Bala says:

    Hi,

    Finally, I understood tech-prefixes :-) !!

    Thanks a lot for the very clear and elaborate explanations and examples !!!

  5. Terry says:

    Thats a very interesting information you have provided about gatekeeper call routing is very good. Here in UK several small business owners use 0845 numbers for call routing. 0845 numbers, more commonly known as local rate numbers make sophisticated call management facilities affordable and accessible to even small and medium scale businesses. With the hosted telephony solutions that come as part of 0845 numbers, small businesses are able to conduct their operations in ways that were previously unthinkable.

    What is it about number ranges such as 0845 and 0844 numbers that provide such flexibility for businesses? There are many features that come along with the service plan for these number ranges. For example, you get to route calls according to the time of the day, location of the caller and availability of staff. If you have many employees on the road, call routing can be a very handy tool. The customer trying to get in touch with a salesperson need not worry about whether he is in the office or is out in the field. The customer calls a number and depending on whether the employee is at his desk or out, either the land line or the mobile phone rings. It can be ensured that the call is routed to the right person every single time. For out of office hours, customers can even leave a voice mail that will be delivered instantly via email. The customer is happy and so is the employee.

  6. Sameer says:

    Intelligent Call Routing, also called automated call distribution (ACD) provides the necessary tools that help a business in allocating incoming calls inside and outside your phone network through multiple extensions. If you are using intelligent call routing in your 0844 and 0845 numbers, the feature Queue Prioritization will help you in prioritizing the most urgent calls. The productivity of employees can be optimized since calls will be routed according to responsibilities, skills and ability. For home based agents, a virtual call center can be set up for their benefit. And above all, you can make sure that there is maximum flexibility of the agents while callers are given the benefit of always having someone available to take their calls through the extensions.
    The rules of distributing calls in the queue to the finest agent are based mainly on longest idle, least busy, round robin and many others. Urgent calls can be answered first because of the existence of program queue priorities thus making it possible for callers to have the best possible experience. Furthermore, high-value customers can be directed to the most suitable agent thru the feature value-based routing. And what makes this feature very useful for organizations with multiple call centers is the ability to balance workloads and evenly distribute incoming calls.

  7. [...] Gatekeeper Call-Routing at a Glance [...]

 

Leave a Reply

Categories

CCIE Bloggers