WikiOld

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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 =====
{{gw_gk.png|}}
  * 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 =====
{{gw-gk1.png|}}
  - **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

{{gw-gk2.png|}}

===== 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.
<code>
gatekeeper
  zone local <zonename> iptel.com <gk-ip>
  no shut
</code>

  * Define other local zone. Device can only register to the gatekeeper if the zone is defined.
  * Subsequent zone does not require the IP address
<code>
gatekeeper
  zone local <zonename1> iptel.com
</code>

=== 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

<code>
  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
</code>


=== 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
<code>
gatekeeper
  gw-type-prefix 1#* default-technology
</code>

=== 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.
<code>
gatekeeper
  gw-type-prefix 011* hopoff ccie gw ipaddr <gw-ip>
</code>

==== Debug ====
  * Show the currently registered gateway to this gatekeeper
<code>
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#
</code>

  * Show the prefixes and their priority
<code>
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# 
</code>

  * Show zone prefix
<code>
Router# show gatekeeper zone prefix

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

Router#
</code>

  * Show any active gatekeeper call
<code>
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#
</code>

  * 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
<code>
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#
</code>

===== 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*. 
<code>
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
</code>

  * 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
<code>
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# 
</code>

  * If we are calling to/from SIP endpoints, we will also need to enable SIP to h323 in both directions
<code>
voice service voip
  allow-connections sip to h323
  allow-connections h323 to sip
</code>

  * Restart the gatekeeper registration process
<code>
no gateway
gateway
</code>

  * Or bounce the H.323 service if there is problem with registration
<code>
voice service voip
  h323
    call service stop
    no call service stop
</code>

==== Debug ====
  * Show gateway registration to gatekeeper
<code>
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#
</code>

  * Debug RAS message
  * Confirm RAS message are sent/receive
<code>
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# 
</code>

===== 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
{{..:cucm:cucm-gk1.png|}}

  * Under **Device > Gatekeeper**
  * Configure the gatekeeper
{{..:cucm:cucm-gk2.png|}}

  * 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.
{{..:cucm:cucm-gk3.png|}}
{{..:cucm:cucm-gk4.png|}}

  * Under **Call Routing > Route/Hunt > Route Pattern**
  * Create Route Pattern
{{..:cucm:cucm-gk5.png|}}

  * 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
{{..:cucm:cucm-gk6.png|}}

<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>