====== 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 , the loopback interface ip is used. gatekeeper zone local iptel.com 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 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 1... [gw-priority 10 gk-trunk_2] zone prefix 1... [gw-priority 9 gk-trunk_1] zone prefix 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 ==== 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 ipaddr 1719** - Causes the gateway to register with the zone at the gatekeeper * **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 ipaddr 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 {{..: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|}} 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