Gatekeeper
- General
- Protocols
- Call Routing
  - Remote Zone
  - Local Zone
- Decision Process
- Technology Prefix
- Gatekeeper
  - Configuration
  - Debug
- Gateway
  - Configuration
  - Debug
- CUCM
  - Configuration

Gatekeeper

General

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.

Call Speed	Gatekeeper Bandwidth Value
G.711 audio call (64 kbps)	128 kbps
G.729 audio call (8 kbps)	16 kbps
128-kbps video call	256 kbps
384-kbps video call	768 kbps
512-kbps video call	1024 kbps
768-kbps video call	1536 kbps

Protocols

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.

Call Routing

Remote Zone

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

Local Zone

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

Decision Process

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

Technology Prefix

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.

Gatekeeper

Configuration

Gatekeeper

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

Zone Prefix

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

Default Tech Prefix

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

GW-TYPE-PREFIX

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>

Debug

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#

Gateway

Configuration

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

Debug

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#

CUCM

Configuration

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>

Table of Contents

Gatekeeper

General

Protocols

Call Routing

Remote Zone

Local Zone

Decision Process

Technology Prefix

Gatekeeper

Configuration

Gatekeeper

Zone Prefix

Default Tech Prefix

GW-TYPE-PREFIX

Debug

Gateway

Configuration

Debug

CUCM

Configuration