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