Cart
Hopoff is a term used on gatekeeper that allows calls to be routed to a specific gateway in a specific zone BYPASSING the use of zone prefixes and BYPASSING the requirement of gateways to register with tech-prefixes.
In order to use HOPOFF on the gatekeeper, both the origination and destination gateways must be registered to the gatekeeper. There is no getting away from this. You can use HOPOFF to route calls to a gateway in any local (defined on your gatekeeper) or remote zone (defined on a different gatekeeper to the one you are configuring).
In the example below we are going to route calls to UCM from the CME using hopoff. First of all the UCM and CME must be registered to the gatekeeper.
HQ-RTR#sh gatek end GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags --------------- ----- --------------- ----- --------- ---- ----- 10.10.110.3 1720 10.10.110.3 56834 Spain VOIP-GW H323-ID: CME Voice Capacity Max.= Avail.= Current.= 0 10.10.210.10 54682 10.10.210.10 33947 US VOIP-GW H323-ID: UCM-TRUNK_1 Voice Capacity Max.= Avail.= Current.= 0 Total number of active registrations = 2
The CME and UCM (Pub only) are both registered to the gatekeeper as shown above. We need not configure zone prefixes and the UCM need not have registered with a technology prefix as shown below.
HQ-RTR#sh gatek zone prefix No zone prefixes defined. HQ-RTR#sh gatekeeper gw GATEWAY TYPE PREFIX TABLE =========================
We are going to route calls beginning with “5″ (in this case to extension 5002) to the UCM without adding a zone prefix and without registering UCM to the GK with a technology prefix.
It is going to be very important to use the Call Signaling Address information shown for the UCM under the show gatekeeper endpoint table so let’s take another look at that information:
HQ-RTR#sh gatek end GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags --------------- ----- --------------- ----- --------- ---- ----- 10.10.210.10 54682 10.10.210.10 33947 US VOIP-GW H323-ID: UCM-TRUNK_1 Voice Capacity Max.= Avail.= Current.= 0
The three vital pieces of information are the IP Address, Call Signaling port and zone name that the UCM is using. The port number UCM is listening on is going to change every time you restart the UCM service so before configuring HOPOFF we must statically set this to the normal H225 signaling port number 1720 (incidentally the CME uses this port number by default). From within UCM service parameters set the following service parameter.
After resetting the trunk within UCM let’s take a look at the show gatekeeper endpoints this time looking out for the Call Signaling port number UCM is using.
HQ-RTR#sh gatek end GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags --------------- ----- --------------- ----- --------- ---- ----- 10.10.210.10 1720 10.10.210.10 33947 US VOIP-GW H323-ID: UCM-TRUNK_1 Voice Capacity Max.= Avail.= Current.= 0
We have statically set the port number UCM is going to use to 1720 and we are ready to add the hopoff command.
gatekeeper zone local Spain ipexpert.com 10.10.110.1 zone local US ipexpert.com gw-type-prefix 5* hopoff US gw ipaddr 10.10.210.10 1720 no shut
Word of warning- do not use the wildcard “.” (dot) when defining any gw-type-prefix. “*” is the only wildcard that can be used whereas “.” and “*” are allowed when defining zone prefixes.
Let’s verfiy this command has had it’s desired effect:
HQ-RTR#sh gatek gw-type-prefix GATEWAY TYPE PREFIX TABLE ========================= Prefix: 5* (Hopoff zone US) Statically-configured gateways (not necessarily currently registered): 10.10.210.10:1720 Zone US master gateway list: 10.10.210.10:1720 UCM-TRUNK_1
We can see above that the HOPOFF is a statically configured gateway and more importantly we see the prefix next to the trunk (master gateway list) as belonging to the same endpoint. If we had not statically set the port number then after a restart of the UCM service we would not see the HOPOFF listed as being the same endpoint as the trunk (master gateway list). See below for an erroneous configuration- you will notice 1730 was the port number being used in the hopoff command when the UCM was indeed using 1720. The trunk does not appear next to the statically configured gateway (hopoff).
HQ-RTR#sh gatek gw GATEWAY TYPE PREFIX TABLE ========================= Prefix: 5* (Hopoff zone US) Statically-configured gateways (not necessarily currently registered): 10.10.210.10:1730
Back to the job in hand. When we make the call we can see that it is successfully routed.
HQ-RTR# debug gatekeeper main 10 Nov 10 03:57:18.615: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Nov 10 03:57:18.615: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48C8A6C0,crv=0x1, answerCall=0 Nov 10 03:57:18.615: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC Nov 10 03:57:18.615: //710496908195/710496908197/GK/gk_dns_query: No Name servers Nov 10 03:57:18.615: //710496908195/710496908197/GK/rassrv_get_addrinfo: (5002) Matched tech-prefix 5 Nov 10 03:57:18.615: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 Nov 10 03:57:18.619: //710496908195/710496908197/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x491FAA04 Nov 10 03:57:18.619: //710496908195/710496908197/GK/rassrv_arq_select_viazone: matched zone is Spain, and z_invianamelen=0 Nov 10 03:57:18.619: //710496908195/710496908197/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x491FAC70 Nov 10 03:57:18.619: //710496908195/710496908197/GK/rassrv_arq_select_viaz HQ-RTR#one: matched zone is US, and z_outvianamelen=0 Nov 10 03:57:18.619: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 Nov 10 03:57:18.619: //710496908195/710496908197/GK/gk_zone_get_proxy_usage: local zone= US, remote zone= Spain, call direction= 0, eptype= 67586 be_entry= 0 Nov 10 03:57:18.619: //710496908195/710496908197/GK/gk_zone_get_proxy_usage: returns proxied = 0 Nov 10 03:57:18.619: //710496908195/710496908197/GK/gk_gw_select_px: Source and destination endpoints in different local zones Nov 10 03:57:18.619: //710496908195/710496908197/GK/gk_zone_get_proxy_usage: local zone= Spain, remote zone= US, call direction= 1, eptype= 67650 be_entry= 0 Nov 10 03:57:18.619: //710496908195/710496908197/GK/gk_zone_get_proxy_usage: returns proxied = 0 Nov 10 03:57:19.023: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Nov 10 03:57:19.023: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48C8A6C0,crv=0x8001, answerCall=1 Nov 10 03:57:19.023: //710496908195/710496908197/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC Nov 10 03:57:19.755: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Nov 10 03:57:19.755: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x4A58CCF8,crv=0x50, answerCall=1
Now hopoff may not be the most scalable way to route calls but it certainly is the easiest and most simple way to route calls. Bear in mind that the same procedure can be used to route calls to remote zones- for example routing calls to India (country code 91) we could simply add the following two commands:
gatekeeper zone local Spain ipexpert.com 10.10.110.1 zone local US ipexpert.com zone remote INDIA ipexpert.com 10.10.100.2 1719 gw-type-prefix 5* hopoff US gw ipaddr 10.10.210.10 1720 gw-type-prefix 91* hopoff INDIA no shutdown
In this case we have no idea of the destination gateway and need only define the remote zone name after specifying the prefix.
Vik Malhi CCIE #13890
Managing Partner / Instructor – IPexpert, Inc.
Tags: ccie voice, CCIE Voice Training, gatekeeper, gatekeeper hopoff, hopoff
