• A single Cisco IOS gatekeeper can provide call routing and call admission control for up to 100 Unified CM clusters in a distributed call processing environment.
• There can be only one active gatekeeper per zone, and you can define up to 100 local zones on a single gatekeeper.
• The bandwidth value deducted by the gatekeeper for every active call is double the bit-rate of the call, excluding Layer 2, IP, and RTP overhead.

• The maximum amount of bandwidth requested by any device in zone A for a single call is 128 kbps, which means that calls trying to use codecs with a higher bit-rate than 64 kbps will be rejected.
• The maximum amount of bandwidth used by all calls involving devices in zone A (either within the zone or with other zones) is 384 kbps, which means that there can be at most three active calls involving devices in zone A.
• The maximum amount of bandwidth used by all calls between devices in zone B and devices in any other zone is 256 kbps, which means that there can be at most two active calls between devices in zone B and devices in zones A, C, and D.
• The maximum amount of bandwidth used by all calls between devices registered with gatekeeper GK 1 and devices registered with any other gatekeeper is 512 kbps, which means that there can be at most four active calls between devices in zones A and B and devices in zones C and D.

To route call to a remote zone, a tech prefix is not required. Just a zone prefix is needed.

To route call between local zones, we must either use

• A default technology prefix
• Non-default technology prefix where the tech-prefix that the destination has registered with is prepended on the originating side
• hopoff tech prefix
• alias registration such as the CME virtual FXS ports registering their number to GK or an alias defined within GK

1. E.164 number match - for instance if the destination is a FXS port or ephone-dn, by default CME registers all the ephone-dn that's register to the telephony service

This is used in combination with the zone prefix to resolve the gateway to use. For instance if we dial 1#1001, the gatekeeper will try to locate a gateway under technology prefix of 1# that has a registered prefix of 1001. The registered prefix is optional. For instance if we registered with 3* as the technology prefix, without any other prefixes, the gatekeeper will forward all request starting with a 3 to this gateway.

When a gateway tries to resolve a an address using ras, it will always send the tech prefix and prefix e.g. 1#1000 to the gatekeeper. If the gateway does not send a tech prefix, the default tech prefix is used if configured on the gatekeeper usually 1#. This however will means that the destination gateway will need to strip the tech prefix 1# off before they can route the call properly.

• If we don't specify a <gk-ip>, the loopback interface ip is used.

gatekeeper
  zone local <zonename> iptel.com <gk-ip>
  no shut

• Define other local zone. Device can only register to the gatekeeper if the zone is defined.
• Subsequent zone does not require the IP address

gatekeeper
  zone local <zonename1> iptel.com

• Use for trunk to call manager trunk whereby we need to specify the priority for a sub and then a pub
• Configure a prefix to associate with a particular zone.
• gw-priority
  • The higher the more prefer
  • By setting it to 0, the gateway is never used
  • Default priority if not configured is 5
• The two device names gk-trunk_1 and gk-trunk_3 are automatically generated by call manager, allow the call manager to register and find the names by running the following commands
  • show gatekeeper endpoints
• Using the zone prefix syntax
  • On the originating gateway, a called number will need to be prepended with the technology prefix that gk-trunk_1 or 2 (CUCM) registered with the gatekeeper e.g. 1#1001. Otherwise the gatekeeper will reject the RAS request as unknown number.
  • On the receiving gateway (CUCM), the technology prefix will need to be stripped before routing to the destination.
• gw-priority - optional only if we want o assign a priority to the gateway

  zone prefix <zone> 1... [gw-priority 10 gk-trunk_2]
  zone prefix <zone> 1... [gw-priority 9 gk-trunk_1]
  zone prefix <zone> 1... [gw-priority 0 BR2-RTR]
  no shut

• With default Tech Prefix
  • Originating gateway will not need to prepend any tech prefix to the called number
  • Receiving gateway will not need to strip any tech prefix to the called number
• Useful when everything can belong under the same tech prefix.
  • Not sure why you would not always use this?
• Default technology prefix is used when there is no technology prefix include in the request
• By default all request without tech prefix will be forwarded to the registered gateway configured with the default technology prefix
• If a technology prefix is not matched in a request, the gatekeeper will pick a gateway registered with the default technology prefix
• However the default technology prefix (usually 1#) is not send to the gateway. So we won't need to do any number stripping on the destination gateway to strip the technology prefix

gatekeeper
  gw-type-prefix 1#* default-technology

• Useful when we are point to gateway where we don't need a priority configured.
• Instead of using the zone prefix, we could us the gw-type-prefix
• In the scenario below, all call beginning with 011 will be forwarded to the gw-ip.
• On the originating gateway (CUCM), we don't need to worry about prepending it with any tech prefix and can just send a request to 011!
• On the receiving gateway, we don't need to worry about stripping any tech prefix before routing the call
• The hopoff keyword is only significant if we also have arq-reject-unknown prefix configured as otherwise it will reject the call if the zone prefix is not defined.

gatekeeper
  gw-type-prefix 011* hopoff ccie gw ipaddr <gw-ip>

• Show the currently registered gateway to this gatekeeper

Router# show gatekeeper endpoints

                    GATEKEEPER ENDPOINT REGISTRATION
                    ================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type    Flags 
--------------- ----- --------------- ----- ---------         ----    ----- 
10.80.103.17    1720  10.80.103.17    57004 ccie              H323-GW 
    H323-ID: BR2-RTR
    Voice Capacity Max.=  Avail.=  Current.= 0
10.80.101.67    1720  10.80.101.67    32817 ccie              VOIP-GW 
    H323-ID: gk-trunk_1
    Voice Capacity Max.=  Avail.=  Current.= 0
10.80.101.72    1720  10.80.101.72    32794 ccie              VOIP-GW 
    H323-ID: gk-trunk_3
    Voice Capacity Max.=  Avail.=  Current.= 0
Total number of active registrations = 3

Router#

• Show the prefixes and their priority

Router# show gatekeeper gw-type-prefix

GATEWAY TYPE PREFIX TABLE
=========================
Prefix: 1#*
  Zone ccie master gateway list:
    10.80.101.67:1720 gk-trunk_1 
    10.80.101.72:1720 gk-trunk_3 
  Zone ccie prefix 5... priority gateway list(s):
   Priority 10:
    10.80.101.72:1720 gk-trunk_3 
   Priority 9:
    10.80.101.67:1720 gk-trunk_1 
  Zone ccie prefix 1... priority gateway list(s):
   Priority 10:
    10.80.101.72:1720 gk-trunk_3 
   Priority 9:
    10.80.101.67:1720 gk-trunk_1 

Prefix: 3*
  Zone ccie master gateway list:
    10.80.103.17:1720 BR2-RTR 

Router# 

• Show zone prefix

Router# show gatekeeper zone prefix

      ZONE PREFIX TABLE
      =================
GK-NAME               E164-PREFIX
-------               -----------
Spain                 34*
PSTN-WAN              91*

Router#

• Show any active gatekeeper call

Router# show gatekeeper call

Total number of active calls = 1.
                         GATEKEEPER CALL INFO
                         ====================
LocalCallID                        Age(secs)   BW
30-33010                           17          128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: gk-trunk_3            5002
           CallSignalAddr  Port  RASSignalAddr   Port
           10.80.101.72    1720  10.80.101.72    32794
 Endpt(s): Alias                 E.164Addr
   dst EP: BR2-RTR               3004
           CallSignalAddr  Port  RASSignalAddr   Port
           10.80.103.17    1720  10.80.103.17    57004

Router#

• Verify call routing on receipt of an ARQ message
  • It show the number request in the ARQ (1#5002)
  • As well as whether the zone, prefix are matched

Router# debug gatekeeper main 10

Sep 25 09:37:47.560: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
Sep 25 09:37:47.560: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x6A9B5C5C,crv=0x44, answerCall=0
Sep 25 09:37:47.560: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/gk_dns_query: No Name servers
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/rassrv_get_addrinfo: (1#5002) Matched tech-prefix 1#
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/rassrv_get_addrinfo: (1#5002) Matched zone prefix 5 and remainder 002
Sep 25 09:37:47.560: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x73CB50C8
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/rassrv_arq_select_viazone: matched zone is ccie, and z_invianamelen=0
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x73CB50C8
Sep 25 09:37:47.560: //62A1A3E78169/62A1A3E7816B/GK/rassrv_arq_select_viazone: matched zone is ccie, and z_outvianamelen=0
Sep 25 09:37:47.560: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1

...
...

Sep 25 09:37:53.628: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
Sep 25 09:37:53.628: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_irr: irrp=0x6A9F87C4, from 10.80.103.17:57004
Sep 25 09:37:54.552: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
Sep 25 09:37:55.672: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup

Router#

• Configure the interface to register with gatekeeper RAS using Unicast
• h323-gateway voip interface - Configures the interface as an H.323 interface
• h323-gateway voip id h323-id BR2-RTR - Identifies the H.323 alias for this gateway
• h323-gateway voip id <zonename> ipaddr <gk-ip> 1719 - Causes the gateway to register with the zone <zonename> at the gatekeeper <gk-ip>
• h323-gateway voip tech-prefix 3 - Configure this gateway to register with the gatekeeper with tech-prefix of 3*.

interface loopback 0
  h323-gateway voip interface
  h323-gateway voip id <zonename> ipaddr <gk-ip> 1719
  h323-gateway voip id h323-id BR2-RTR
  h323-gateway voip tech-prefix 3

• Configure dial-peer to use ras for lookup
• The tech-prefix 1# is prepend to all request to the gatekeeper.
  • When dialing 1001, this gateway will send a request of 1#1001 to the gatekeeper.
  • The 1# will also be send to the destination gateway/cucm and will need to be stripped.
• If we don't specify a tech-prefix here, we can also use the default technology prefix configure on the gatekeeper

voice class codec 1
  codec preference 1 g711ulaw
  codec preference 2 g729r8  
!
dial-peer voice 15 voip
  destination-pattern 1...
  voice-class codec 1
  session target ras
  no vad
  tech-prefix 1# 

• If we are calling to/from SIP endpoints, we will also need to enable SIP to h323 in both directions

voice service voip
  allow-connections sip to h323
  allow-connections h323 to sip

• Restart the gatekeeper registration process

no gateway
gateway

• Or bounce the H.323 service if there is problem with registration

voice service voip
  h323
    call service stop
    no call service stop

• Show gateway registration to gatekeeper

Router# show gateway

H.323 ITU-T Version: 4.0   H323 Stack Version: 0.1 

 H.323 service is up
 Gateway  BR2-RTR  is registered to Gatekeeper ccie

Alias list (CLI configured) 
 H323-ID BR2-RTR
Alias list (last RCF) 
 H323-ID BR2-RTR

 H323 resource thresholding is Disabled

Router#

• Debug RAS message
• Confirm RAS message are sent/receive

Router# debug ras

ep 25 09:44:39.575: RASLib::GW_RASSendRRQ: RRQ (seq# 534) sent to 10.80.101.78
Sep 25 09:44:39.575: h323chan_chn_process_read_socket
Sep 25 09:44:39.575: h323chan_chn_process_read_socket: fd=2 of type CONNECTED has data
Sep 25 09:44:39.575:  h323chan_chn_process_read_socket: h323chan accepted/connected fd=2

Sep 25 09:44:39.575: h323chan_dgram_recvdata:rcvd from [10.80.101.78:1719] on fd=2

Sep 25 09:44:39.575: RCF (seq# 534) rcvd
Sep 25 09:44:46.212: h323chan_chn_process_read_socket
Sep 25 09:44:46.212: h323chan_chn_process_read_socket: fd=0 of type LISTENING has data
Sep 25 09:44:46.212: h323chan_chn_process_read_socket
Sep 25 09:44:46.212: h323chan_chn_process_read_socket: fd=3 of type ACCEPTED has data
Sep 25 09:44:46.212:  h323chan_chn_process_read_socket: h323chan accepted/connected fd=3
h323chan_dgram_send:Sent UDP msg. Bytes sent: 191 to 10.80.101.78:1719 fd=2

Sep 25 09:44:46.216: RASLib::GW_RASSendARQ: ARQ (seq# 535) sent to 10.80.101.78
Sep 25 09:44:46.216: h323chan_chn_process_read_socket
Sep 25 09:44:46.216: h323chan_chn_process_read_socket: fd=2 of type CONNECTED has data
Sep 25 09:44:46.216:  h323chan_chn_process_read_socket: h323chan accepted/connected fd=2

Sep 25 09:44:46.216: h323chan_dgram_recvdata:rcvd from [10.80.101.78:1719] on fd=2

Sep 25 09:44:46.216: ACF (seq# 535) rcvdparse_ras_usage_info_types: Ras Usage Info Nonstd decode succeeded, remlen = 103
Sep 25 09:44:48.384: h323chan_chn_process_read_socket
Sep 25 09:44:48.384: h323chan_chn_process_read_socket: fd=3 of type ACCEPTED has data
Sep 25 09:44:48.384:  h323chan_chn_process_read_socket: h323chan accepted/connected fd=3

Router# 

• By default call manager will use a random port to register the gatekeeper, we can force it to use a static port. This could cause problem if we reboot the callmanager and the gatekeeper didn't update itself.
• Under Service Parameter > CallManager
• Make sure the name matches what we configured on the h225 gatekeeper controlled trunk

• Under Device > Gatekeeper
• Configure the gatekeeper

• Under Device > Trunk
• Configure the h225 gatekeeper controlled trunk
• Wait for far end h.245 TCS - Uncheck
  • Symptom - The called party IP phone rings at the target location, but silence is heard when answered. The calling party continues to hear ringback. The call is cleared down after a few rings with cause code 47
  • This check box specifies that the Cisco CallManager must receive the far-end H.245 TCS before it sends its H.245 TCS.
  • If left checked, the H.323 devices at both sides of the trunk will wait for the far end to send TCS first and the H.245 connection times out after a few seconds.
  • Unchecking enables Cisco CallManager to send the Terminal Capability Set (TCS) without waiting for the other side.

• Under Call Routing > Route/Hunt > Route Pattern
• Create Route Pattern

• Strip the Technology prefix
  • The technology prefix is send together with the dial number e.g. (1#1001)
  • The technology prefix is not send if we are using the default technology prefix
• If the H323 gateway IP is already defined, the significant digits must be set in here
• If not the significant digits are set on the H225 trunk

<note important>If the same router is configured as an H.323 gateway and H.323 GK Trunk, the setting in the H.323 gateway will take precedent when a call comes in</note>