Differences

This shows you the differences between two versions of the page.

--- eduardo:cisco:gw:gw-gk [2010/09/25 10:45] – eduardo
+++ eduardo:cisco:gw:gw-gk [2024/02/23 08:19] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== 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
+--------------- ----- --------------- ----- ---------         ----    -----
+.80.103.17    1720  10.80.103.17    57004 ccie              H323-GW
+    H323-ID: BR2-RTR
+    Voice Capacity Max.=  Avail.=  Current.= 0
+.80.101.67    1720  10.80.101.67    32817 ccie              VOIP-GW
+    H323-ID: gk-trunk_1
+    Voice Capacity Max.=  Avail.=  Current.= 0
+.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:
+.80.101.67:1720 gk-trunk_1
+.80.101.72:1720 gk-trunk_3
+  Zone ccie prefix 5... priority gateway list(s):
+   Priority 10:
+.80.101.72:1720 gk-trunk_3
+   Priority 9:
+.80.101.67:1720 gk-trunk_1
+  Zone ccie prefix 1... priority gateway list(s):
+   Priority 10:
+.80.101.72:1720 gk-trunk_3
+   Priority 9:
+.80.101.67:1720 gk-trunk_1
+Prefix: 3*
+  Zone ccie master gateway list:
+.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
+-33010                           17          128(Kbps)
+ Endpt(s): Alias                 E.164Addr
+   src EP: gk-trunk_3            5002
+           CallSignalAddr  Port  RASSignalAddr   Port
+.80.101.72    1720  10.80.101.72    32794
+ Endpt(s): Alias                 E.164Addr
+   dst EP: BR2-RTR               3004
+           CallSignalAddr  Port  RASSignalAddr   Port
+.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>