[OSL | CCIE_Voice] GATEKEEPER ISSUE
Greetings All. I'm having an unusual issue with my Gatekeeper which I have not seen before. My gatekeeper is on the mgcp HQ router. When I do show gatekeeper end I only see GK_Trunk_1, the publisher and CME. The Subscriber is missing. I have reset the trunk and gatekeeper many times. Although the database shows 412's and 2's I performed a DB repair all. I have tried everything to get GK_Tunk_2, the subscriber to come up but it won't. Anyone out there experience this issue and did you find a resolution? If so please respond ASAP as my lab is in 9 days and if this happens to me in the lab I'd like to know what I have to do to fix it. Any input appreciated. Thank you. Michael Sears ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] GATEKEEPER ISSUE
Hi Michael Check that the device pool associated to the trunk got a Call Manager group with both Pub and Sub. Beside of that I don't know Regards PS: Never ask to answer ASAP please :) We are like you and owe nothing but help if we can :) Nic Le Wednesday, February 20, 2013 1:43:06 PM, michael.se...@compucom.com a écrit : Greetings All. I'm having an unusual issue with my Gatekeeper which I have not seen before. My gatekeeper is on the mgcp HQ router. When I do show gatekeeper end I only see GK_Trunk_1, the publisher and CME. The Subscriber is missing. I have reset the trunk and gatekeeper many times. Although the database shows 412's and 2's I performed a DB repair all. I have tried everything to get GK_Tunk_2, the subscriber to come up but it won't. Anyone out there experience this issue and did you find a resolution? If so please respond ASAP as my lab is in 9 days and if this happens to me in the lab I'd like to know what I have to do to fix it. Any input appreciated. Thank you. Michael Sears ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] GATEKEEPER ISSUE
Thank you much. You were right on. Somehow I set the device pool incorrectly I'm just upset with myself for not checking this, but thank you much was driving me crazy. Hopefully, I won't make this stupid mistake in my lab attempt. Oh and thanks for responding so quickly. --ms Michael Sears -Original Message- From: Nicolas MICHEL [mailto:mcl.nico...@gmail.com] Sent: Wednesday, February 20, 2013 6:10 AM To: Sears, Michael (msears) Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] GATEKEEPER ISSUE Hi Michael Check that the device pool associated to the trunk got a Call Manager group with both Pub and Sub. Beside of that I don't know Regards PS: Never ask to answer ASAP please :) We are like you and owe nothing but help if we can :) Nic Le Wednesday, February 20, 2013 1:43:06 PM, michael.se...@compucom.com a écrit : Greetings All. I'm having an unusual issue with my Gatekeeper which I have not seen before. My gatekeeper is on the mgcp HQ router. When I do show gatekeeper end I only see GK_Trunk_1, the publisher and CME. The Subscriber is missing. I have reset the trunk and gatekeeper many times. Although the database shows 412's and 2's I performed a DB repair all. I have tried everything to get GK_Tunk_2, the subscriber to come up but it won't. Anyone out there experience this issue and did you find a resolution? If so please respond ASAP as my lab is in 9 days and if this happens to me in the lab I'd like to know what I have to do to fix it. Any input appreciated. Thank you. Michael Sears ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Hello, I know the problem cause. 1st on CUCM: The sub was removed from callmanager group. 2nd on BR2-RTR: This command was missing - h323-gateway voip bind srcaddr 177.1.254.3 Thanks, From: Amy Ryan [mailto:ar...@ipexpert.com] Sent: Friday, October 15, 2010 4:01 PM To: Tamer Ismail; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue Tamer, Can you supply the following? -sh gatek endp -sh gatek gw-ty Thank you, Amy --- Amy Ryan - CCIE #24677 (Voice) Technical Instructor - IPexpert, Inc. Mailto: ar...@ipexpert.com Telephone: +1.810.326.1444 Live Assistance, Please visit: www.ipexpert.com/chat http://www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (RS, Voice, Wireless, Security Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at www.ipexpert.com/communities http://www.ipexpert.com/communities and our public website at www.ipexpert.com http://www.ipexpert.com/ _ From: Tamer Ismail tih...@gmail.com Date: Fri, 15 Oct 2010 01:34:00 +0200 To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Gatekeeper Issue Hello Experts, I have problem in integrating GK with CUCM and BR2, showing below all configuration I made for the integration. The problem in prefix #1 the only prefix register on GW (3 is not, which should come from BR2). And also CUCM pub is the old server register to GK (sub is not). Please check configuration and tell me, maybe I forget something. HQ-RTR: == ! voice service voip sip bind control source-interface FastEthernet0/0.11 bind media source-interface FastEthernet0/0.11 ! gatekeeper zone local PL proctorlabs.com zone prefix PL 1... gw-priority 10 gk-trunk_2 zone prefix PL 5... gw-priority 10 gk-trunk_2 zone prefix PL 1... gw-priority 9 gk-trunk_1 zone prefix PL 5... gw-priority 9 gk-trunk_1 zone prefix PL 1... gw-priority 0 BR2-RTR zone prefix PL 5... gw-priority 0 BR2-RTR no shutdown ! BR2-RTR: === ! interface Loopback0 ip address 177.1.254.3 255.255.255.255 h323-gateway voip interface h323-gateway voip id PL ipaddr 177.1.11.1 1719 h323-gateway voip h323-id BR2-RTR h323-gateway voip tech-prefix 3 ! voice service voip allow-connections h323 to sip allow-connections sip to h323 h323 h225 listen-port 1820 no call service stop ! CUCM: = .Add GK .Add Trunk .Change service parameter with gk-trunk value. .Change signaling port in gateway page to be 1820 Any way I think CUCM configuration should not affect Sub only to not be register. Thanks in advance, Tamer _ ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Tamer, Can you supply the following? -sh gatek endp -sh gatek gw-ty Thank you, Amy --- Amy Ryan CCIE #24677 (Voice) Technical Instructor - IPexpert, Inc. Mailto: ar...@ipexpert.com Telephone: +1.810.326.1444 Live Assistance, Please visit: www.ipexpert.com/chat http://www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (RS, Voice, Wireless, Security Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at www.ipexpert.com/communities http://www.ipexpert.com/communities and our public website at www.ipexpert.com http://www.ipexpert.com/ From: Tamer Ismail tih...@gmail.com Date: Fri, 15 Oct 2010 01:34:00 +0200 To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Gatekeeper Issue Hello Experts, I have problem in integrating GK with CUCM and BR2, showing below all configuration I made for the integration. The problem in prefix #1 the only prefix register on GW (3 is not, which should come from BR2). And also CUCM pub is the old server register to GK (sub is not). Please check configuration and tell me, maybe I forget something. HQ-RTR: == ! voice service voip sip bind control source-interface FastEthernet0/0.11 bind media source-interface FastEthernet0/0.11 ! gatekeeper zone local PL proctorlabs.com zone prefix PL 1... gw-priority 10 gk-trunk_2 zone prefix PL 5... gw-priority 10 gk-trunk_2 zone prefix PL 1... gw-priority 9 gk-trunk_1 zone prefix PL 5... gw-priority 9 gk-trunk_1 zone prefix PL 1... gw-priority 0 BR2-RTR zone prefix PL 5... gw-priority 0 BR2-RTR no shutdown ! BR2-RTR: === ! interface Loopback0 ip address 177.1.254.3 255.255.255.255 h323-gateway voip interface h323-gateway voip id PL ipaddr 177.1.11.1 1719 h323-gateway voip h323-id BR2-RTR h323-gateway voip tech-prefix 3 ! voice service voip allow-connections h323 to sip allow-connections sip to h323 h323 h225 listen-port 1820 no call service stop ! CUCM: = ·Add GK ·Add Trunk ·Change service parameter with gk-trunk value. ·Change signaling port in gateway page to be 1820 Any way I think CUCM configuration should not affect Sub only to not be register. Thanks in advance, Tamer ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
[OSL | CCIE_Voice] Gatekeeper Issue
Hello Experts, I have problem in integrating GK with CUCM and BR2, showing below all configuration I made for the integration. The problem in prefix #1 the only prefix register on GW (3 is not, which should come from BR2). And also CUCM pub is the old server register to GK (sub is not). Please check configuration and tell me, maybe I forget something. HQ-RTR: == ! voice service voip sip bind control source-interface FastEthernet0/0.11 bind media source-interface FastEthernet0/0.11 ! gatekeeper zone local PL proctorlabs.com zone prefix PL 1... gw-priority 10 gk-trunk_2 zone prefix PL 5... gw-priority 10 gk-trunk_2 zone prefix PL 1... gw-priority 9 gk-trunk_1 zone prefix PL 5... gw-priority 9 gk-trunk_1 zone prefix PL 1... gw-priority 0 BR2-RTR zone prefix PL 5... gw-priority 0 BR2-RTR no shutdown ! BR2-RTR: === ! interface Loopback0 ip address 177.1.254.3 255.255.255.255 h323-gateway voip interface h323-gateway voip id PL ipaddr 177.1.11.1 1719 h323-gateway voip h323-id BR2-RTR h323-gateway voip tech-prefix 3 ! voice service voip allow-connections h323 to sip allow-connections sip to h323 h323 h225 listen-port 1820 no call service stop ! CUCM: = . Add GK . Add Trunk . Change service parameter with gk-trunk value. . Change signaling port in gateway page to be 1820 Any way I think CUCM configuration should not affect Sub only to not be register. Thanks in advance, Tamer ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
[OSL | CCIE_Voice] Gatekeeper Issue
Hi everyone, I am having trouble with my GK. I have made Bold what is the problem, but I can't seem to understand why I'm having this issue. I configured a tech-prefix of 1# under the Trunk configuration page. Here is the config - gatekeeper zone local ZONE_1 asccie.com 10.5.200.1 zone prefix ZONE_1 1* gw-priority 10 CUCM_GK_TRUNK_2 zone prefix ZONE_1 1* gw-priority 9 CUCM_GK_TRUNK_1 zone prefix ZONE_1 1* gw-priority 0 BR2_R3_GW BR1_R2_GW zone prefix ZONE_1 44* gw-priority 10 BR2_R3_GW zone prefix ZONE_1 44* gw-priority 0 BR1_R2_GW CUCM_GK_TRUNK_2 CUCM_GK_TRUNK_1 gw-type-prefix 1#* default-technology no shutdown Here is the debug gatekeeper main 10 output: May 25 23:55:58.011: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:55:58.187: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1(config-gk)# May 25 23:56:00.115: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:56:00.115: ////GK/gk_rassrv_arq: arqp=0x4AE0FB04,crv=0x19, answerCall=0 May 25 23:56:00.115: ////GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_dns_query: No Name servers May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched tech-prefix 1# May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_invian R1(config-gk)#amelen=0 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_outvianamelen=0 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) tech-prefix gateway selection failed. May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_rassrv_sep_arq: rassrv_get_addrinfo() failed (return code = 0x103) Here is the show gatekeeper call 10 output: May 26 00:02:15.899: ////GK/gk_call_new: src_endptp=0x4AE0F9F0, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=31, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x4925F3F8 May 26 00:02:15.899: ////GK/gk_call_find_endpts: NOT_FOUND May 26 00:02:15.899: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4AE0F9F0 May 26 00:02:15.899: //C6CEF7C380D2/C6CEF7C380D4/GK/gk_call_delete: callp=4AB57F54 May 26 00:02:15.899: //C6CEF7C380D2/C6CEF7C380D4/GK/gk_call_delete: c_callstate 0x0, c_resbw1 0, resbw2 0, c_reszp1 0x0, c_reszp2 0x0 Here is the show gatekeeper endpoints output: R1(config-gk)#do show gatekeeper end GATEKEEPER ENDPOINT REGISTRATION CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags --- - --- - - - 10.5.201.1 1720 10.5.201.1 61751 ZONE_1VOIP-GW H323-ID: BR1_R2_GW Voice Capacity Max.= Avail.= Current.= 0 10.5.202.1 1720 10.5.202.1 52635 ZONE_1VOIP-GW H323-ID: BR2_R3_GW E164-ID: 3001 E164-ID: 3002 Voice Capacity Max.= Avail.= Current.= 0 172.21.51.204 37257 172.21.51.204 32858 ZONE_1TERM H323-ID: CUCM_GK_TRUNK_1 172.21.51.205 34279 172.21.51.205 32814 ZONE_1TERM H323-ID: CUCM_GK_TRUNK_2 Total number of active registrations = 4 (The reason why 3001 and 3002 are registering with GK is the fact that I am using the secondary command on CME. For some reason that is still letting 3001/3002 register with the GK). Thanks in advance for your help! Jeff Price Network Consulting Engineer - Unified Communications Practice jeffp...@cisco.com mailto:jeffp...@cisco.com Phone: 408-525-8293 Mobile: 408-204-4510 Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134-1706 USA Cisco home page http://www.cisco.com/ Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the
Re: [OSL | CCIE_Voice] Gatekeeper Issue
-it.net Cc: ccie_voice@onlinestudylist.com Message-ID: 4bfc4d65.8060...@cbi.ma Content-Type: text/plain; charset=iso-8859-1 Congratulations brother On 05/25/2010 11:18 PM, Ehab Salem wrote: Dear Group, I Passed from the first shot Really thanks a lot for all your help...I really learned a lot from this kind study list J All what I want to say about my experience: the exam is easier than what we have in Volume 2...so it's all about Time Management, Strategy and Plan. I finished the lab in almost 6 hours. And spent the rest of time revising my configuration. I spent the week before the exam practicing on time management and putting a strategy and plan for each part in the exam that may comeand before the exam you should sleep well to start the exam with your full performance and energy. Anyway, it's over now for me...and wish u all the best J Thanks and best regards, * * *E**HAB **S**ALEM* Cisco Instructor | Sigma IT -- Egypt ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com -- next part -- An HTML attachment was scrubbed... URL: http://onlinestudylist.com/pipermail/ccie_voice/attachments/20100525/f4b 052ec/attachment-0001.htm -- Message: 3 Date: Tue, 25 May 2010 23:25:25 +0100 From: Ashar Siddiqui siddas...@gmail.com Subject: Re: [OSL | CCIE_Voice] I Passed CCIE#26088!!! To: kerboute kerboute naoufal.kerbo...@cbi.ma Cc: ccie_voice@onlinestudylist.com Message-ID: 4bfc4e55.9060...@gmail.com Content-Type: text/plain; charset=us-ascii An HTML attachment was scrubbed... URL: http://onlinestudylist.com/pipermail/ccie_voice/attachments/20100525/b50 0a27a/attachment-0001.htm -- Message: 4 Date: Tue, 25 May 2010 17:53:56 -0500 From: Jeff Price (jeffpric) jeffp...@cisco.com Subject: [OSL | CCIE_Voice] Gatekeeper Issue To: CCIE Voice Maillist ccie_voice@onlinestudylist.com Message-ID: b2de0afa86565c47bd3a8435550f955301068...@xmb-rcd-201.cisco.com Content-Type: text/plain; charset=us-ascii Hi everyone, I am having trouble with my GK. I have made Bold what is the problem, but I can't seem to understand why I'm having this issue. I configured a tech-prefix of 1# under the Trunk configuration page. Here is the config - gatekeeper zone local ZONE_1 asccie.com 10.5.200.1 zone prefix ZONE_1 1* gw-priority 10 CUCM_GK_TRUNK_2 zone prefix ZONE_1 1* gw-priority 9 CUCM_GK_TRUNK_1 zone prefix ZONE_1 1* gw-priority 0 BR2_R3_GW BR1_R2_GW zone prefix ZONE_1 44* gw-priority 10 BR2_R3_GW zone prefix ZONE_1 44* gw-priority 0 BR1_R2_GW CUCM_GK_TRUNK_2 CUCM_GK_TRUNK_1 gw-type-prefix 1#* default-technology no shutdown Here is the debug gatekeeper main 10 output: May 25 23:55:58.011: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:55:58.187: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1(config-gk)# May 25 23:56:00.115: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:56:00.115: ////GK/gk_rassrv_arq: arqp=0x4AE0FB04,crv=0x19, answerCall=0 May 25 23:56:00.115: ////GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_dns_query: No Name servers May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched tech-prefix 1# May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_invian R1(config-gk)#amelen=0 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_outvianamelen=0 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) tech-prefix gateway selection failed. May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_rassrv_sep_arq: rassrv_get_addrinfo() failed (return code = 0x103) Here is the show gatekeeper call 10 output: May 26 00:02:15.899: ////GK/gk_call_new: src_endptp=0x4AE0F9F0, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=31, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x4925F3F8 May
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Hi Jeff, Have you tried following configuration. If not, give it a shot. ! gatekeeper zone local ZONE_1 asccie.com 10.5.200.1 zone prefix ZONE_1 1775... gw-priority 10 CUCM_GK_TRUNK_2 zone prefix ZONE_1 1775... gw-priority 9 CUCM_GK_TRUNK_1 zone prefix ZONE_1 1775... gw-priority 0 BR2_R3_GW BR1_R2_GW zone prefix ZONE_1 44* gw-priority 10 BR2_R3_GW zone prefix ZONE_1 44* gw-priority 0 BR1_R2_GW CUCM_GK_TRUNK_2 CUCM_GK_TRUNK_1 gw-type-prefix 1# default-technology no shutdown ! Hope that helps, Tapan From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Jeff Price (jeffpric) Sent: Tuesday, May 25, 2010 5:54 PM To: CCIE Voice Maillist Subject: [OSL | CCIE_Voice] Gatekeeper Issue Hi everyone, I am having trouble with my GK. I have made Bold what is the problem, but I can't seem to understand why I'm having this issue. I configured a tech-prefix of 1# under the Trunk configuration page. Here is the config - gatekeeper zone local ZONE_1 asccie.com 10.5.200.1 zone prefix ZONE_1 1* gw-priority 10 CUCM_GK_TRUNK_2 zone prefix ZONE_1 1* gw-priority 9 CUCM_GK_TRUNK_1 zone prefix ZONE_1 1* gw-priority 0 BR2_R3_GW BR1_R2_GW zone prefix ZONE_1 44* gw-priority 10 BR2_R3_GW zone prefix ZONE_1 44* gw-priority 0 BR1_R2_GW CUCM_GK_TRUNK_2 CUCM_GK_TRUNK_1 gw-type-prefix 1#* default-technology no shutdown Here is the debug gatekeeper main 10 output: May 25 23:55:58.011: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:55:58.187: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1(config-gk)# May 25 23:56:00.115: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:56:00.115: ////GK/gk_rassrv_arq: arqp=0x4AE0FB04,crv=0x19, answerCall=0 May 25 23:56:00.115: ////GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_dns_query: No Name servers May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched tech-prefix 1# May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_invian R1(config-gk)#amelen=0 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_outvianamelen=0 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) tech-prefix gateway selection failed. May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_rassrv_sep_arq: rassrv_get_addrinfo() failed (return code = 0x103) Here is the show gatekeeper call 10 output: May 26 00:02:15.899: ////GK/gk_call_new: src_endptp=0x4AE0F9F0, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=31, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x4925F3F8 May 26 00:02:15.899: ////GK/gk_call_find_endpts: NOT_FOUND May 26 00:02:15.899: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4AE0F9F0 May 26 00:02:15.899: //C6CEF7C380D2/C6CEF7C380D4/GK/gk_call_delete: callp=4AB57F54 May 26 00:02:15.899: //C6CEF7C380D2/C6CEF7C380D4/GK/gk_call_delete: c_callstate 0x0, c_resbw1 0, resbw2 0, c_reszp1 0x0, c_reszp2 0x0 Here is the show gatekeeper endpoints output: R1(config-gk)#do show gatekeeper end GATEKEEPER ENDPOINT REGISTRATION CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags --- - --- - - - 10.5.201.1 1720 10.5.201.1 61751 ZONE_1VOIP-GW H323-ID: BR1_R2_GW Voice Capacity Max.= Avail.= Current.= 0 10.5.202.1 1720 10.5.202.1 52635 ZONE_1VOIP-GW H323-ID: BR2_R3_GW E164-ID: 3001 E164-ID: 3002 Voice Capacity Max.= Avail.= Current.= 0 172.21.51.204 37257 172.21.51.204 32858 ZONE_1TERM H323-ID: CUCM_GK_TRUNK_1 172.21.51.205 34279 172.21.51.205 32814 ZONE_1TERM H323-ID: CUCM_GK_TRUNK_2 Total number of active registrations = 4
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Jeff, You were using trunks as terminal. I seem to remember that terminals can not specify a tech prefix. Change the type to VOIP-GW and give it a try. Bo On Tue, May 25, 2010 at 3:53 PM, Jeff Price (jeffpric) jeffp...@cisco.comwrote: Hi everyone, I am having trouble with my GK. I have made *Bold* what is the problem, but I can’t seem to understand why I’m having this issue. I configured a tech-prefix of 1# under the Trunk configuration page. Here is the config – gatekeeper zone local ZONE_1 asccie.com 10.5.200.1 zone prefix ZONE_1 1* gw-priority 10 CUCM_GK_TRUNK_2 zone prefix ZONE_1 1* gw-priority 9 CUCM_GK_TRUNK_1 zone prefix ZONE_1 1* gw-priority 0 BR2_R3_GW BR1_R2_GW zone prefix ZONE_1 44* gw-priority 10 BR2_R3_GW zone prefix ZONE_1 44* gw-priority 0 BR1_R2_GW CUCM_GK_TRUNK_2 CUCM_GK_TRUNK_1 gw-type-prefix 1#* default-technology no shutdown Here is the debug gatekeeper main 10 output: May 25 23:55:58.011: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:55:58.187: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1(config-gk)# May 25 23:56:00.115: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup May 25 23:56:00.115: ////GK/gk_rassrv_arq: arqp=0x4AE0FB04,crv=0x19, answerCall=0 May 25 23:56:00.115: ////GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_dns_query: No Name servers May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched tech-prefix 1# May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_invian R1(config-gk)#amelen=0 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4AE06200 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_arq_select_viazone: matched zone is ZONE_1, and z_outvianamelen=0 May 25 23:56:00.115: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/rassrv_get_addrinfo: (1#17752011001) *tech-prefix gateway selection failed*. May 25 23:56:00.115: //E69BDC8380B8/E69BDC8380BA/GK/gk_rassrv_sep_arq: rassrv_get_addrinfo() failed (return code = 0x103) Here is the show gatekeeper call 10 output: May 26 00:02:15.899: ////GK/gk_call_new: src_endptp=0x4AE0F9F0, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=31, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x4925F3F8 May 26 00:02:15.899: ////GK/gk_call_find_endpts: NOT_FOUND May 26 00:02:15.899: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4AE0F9F0 May 26 00:02:15.899: //C6CEF7C380D2/C6CEF7C380D4/GK/gk_call_delete: callp=4AB57F54 May 26 00:02:15.899: //C6CEF7C380D2/C6CEF7C380D4/GK/gk_call_delete: c_callstate 0x0, c_resbw1 0, resbw2 0, c_reszp1 0x0, c_reszp2 0x0 Here is the show gatekeeper endpoints output: R1(config-gk)#do show gatekeeper end GATEKEEPER ENDPOINT REGISTRATION CallSignalAddr Port RASSignalAddr Port Zone Name TypeFlags --- - --- - - - 10.5.201.1 1720 10.5.201.1 61751 ZONE_1VOIP-GW H323-ID: BR1_R2_GW Voice Capacity Max.= Avail.= Current.= 0 10.5.202.1 1720 10.5.202.1 52635 ZONE_1VOIP-GW H323-ID: BR2_R3_GW E164-ID: 3001 E164-ID: 3002 Voice Capacity Max.= Avail.= Current.= 0 172.21.51.204 37257 172.21.51.204 32858 ZONE_1TERM H323-ID: CUCM_GK_TRUNK_1 172.21.51.205 34279 172.21.51.205 32814 ZONE_1TERM H323-ID: CUCM_GK_TRUNK_2 Total number of active registrations = 4 (The reason why 3001 and 3002 are registering with GK is the fact that I am using the secondary command on CME. For some reason that is still letting 3001/3002 register with the GK). Thanks in advance for your help! [image: http://www.cisco.com/cisco/web/UK/images/emails/signaturetool/the_human_network_logo.jpg] *Jeff Price** Network Consulting Engineer - Unified Communications Practice* * * jeffp...@cisco.com Phone: *408-525-8293* Mobile: *408-204-4510*
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Hi, I have restored and begun another lab already so I am unable to supply this debug. However, I realized I had the H225 Trunk was assigned to the HQ_DP, which used the HQ_REG, which requested G711. Eventually G729 was negotiated, because that's all that the BR2 would allow. I assigned the trunk to the correct DP, and the correct bandwidth was then requested. Jeff From: Angel Perez [mailto:gorr...@hotmail.com] Sent: Monday, February 22, 2010 2:17 AM To: afat...@verizon.net; Jeff Price (jeffpric) Cc: osl osl Subject: RE: [OSL | CCIE_Voice] Gatekeeper Issue Hello: If the gk trunk has inbound fast start checked, the gk will ask for 128k of bandwith then with a BRQ message it will reduce the bw to 16k, a debug h225 asn1 would be clarifaing. Jeff: Can you provide the following debug: deb h225 asn1 thx Date: Fri, 19 Feb 2010 18:48:47 -0800 From: afat...@verizon.net To: jeffp...@cisco.com CC: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue whats the direction of call? Previous debug has bandwidth 160, which is 16k for g729 and this one is showing bandwidth 1280 which is 128k for g711. So this call leg debug is showing is g711 is being requested somwhere. -- Mustafa Jeff Price (jeffpric) wrote: Here is the output of command debug gatekeeper call 10: *Feb 20 03:38:14.913: ////GK/gk_call_new: src_endptp=0x4ABCA7A8, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=61, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:14.913: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:14.913: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4ABCA7A8 *Feb 20 03:38:14.937: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:14.937: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:15.005: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:15.005: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:24.397: ////GK/gk_call_find_crv: endptp=0x4ABCA7A8, crv=61: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is SEP *Feb 20 03:38:24.397: ////GK/gk_call_clear_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x801, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C R1# *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C01, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.425: ////GK/gk_call_find_dstendpt: NOT_FOUND *Feb 20 03:38:24.425: ////GK/gk_call_new: src_endptp=0x47621FB0, dst_endptp=0x4ABFA848, src_pxp=0x0, dst_pxp=0x0, bw=1280, crv=32830, whichcrv=0x2, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:24.425: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:24.429: ////GK/gk_call_new: checking for default (CLI) carrier for dep endpt 0x4ABFA848 R1# *Feb 20 03:38:29.449: ////GK/gk_call_clear_crv: endptp=0x4ABFA848, crv=32830: *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x800, c_resbw1 0, resbw2 1280, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A57164C *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x6C00, c_resbw1 0, resbw2 0, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: ////GK/gk_call_clear_crv: endptp=0x4ABCA7A8, crv=61: R1# *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is SEP *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 The gk_call_find_endpts: NOT_FOUND line is leading me to believe something that I was noticed on the debug gatekeeper main 10 command: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001
Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India
Hi Kevin, I'm a bit off here, cause GK isn't my strongest area, but shouldn't the line with the default tech-prefix look like this? gw-type-prefix 1# default-technology IE, no * after the # Maybe it's not it, but it's my 2 cent. Roger Källberg Consultant Cygate AB Eric Perssons väg 21, SE-217 62 MALMÖ Från: Kevin Hobson [kevin.hobson2...@ntlworld.com] Skickat: den 19 februari 2010 07:28 Till: o...@ipexpert.com; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Ämne: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Otto, Please see my config for the GK on the PSTN below: gatekeeper zone local PSTN-WAN ipexpert.com 10.100.1.1 zone remote HQ-RTR ipexpert.com 10.100.200.2 1719 zone remote US ipexpert.com 10.10.110.1 1719 zone prefix PSTN-WAN 34* zone prefix PSTN-WAN 91* gw-type-prefix 1#* default-technology no shutdown ! interface FastEthernet0/1 ip address 10.100.1.1 255.255.255.0 ip ospf network broadcast duplex full speed 100 h323-gateway voip interface h323-gateway voip id PSTN-WAN ipaddr 10.100.1.1 1719 h323-gateway voip h323-id pstn-gw h323-gateway voip bind srcaddr 10.100.1.1 h323-gateway voip tech-prefix 1# no shut It looks correct. It just seems that it is not going on to look to for a Default Techprefix which should then route it to the PSTN-WAN Zone. Please note my lab is a mixture of physical and virtual devices using a combination of GNS3 and Cisco routers. I will move the PSTN config to a physical device today when i get to the office just to rule out the virtual not being able to do this kind of thing. Thanks Kev -Original Message- From: o...@ipexpert.com [mailto:o...@ipexpert.com] Sent: 19 February 2011 04:12 To: Kevin Hobson; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Kevin, According to your hq debug, the call is being properly routed to the pstn remote zone, therefore your hq rtr configuration should be good. I would like to check your pstn wan gk configuration, would you please sent it? Thanks, Enviado desde mi BlackBerry de Movistar -Original Message- From: Kevin Hobson kevin.hobson2...@ntlworld.com Date: Thu, 18 Feb 2010 18:00:42 To: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India I have an issue with Lab5c where when i call India it just stops on the PSTN-WAN router at proxy on debug gatek main 10. After this the timer expires on the UCM and fails to complete. See below: HQ-RTR Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Tech-prefix match failed. Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Matched zone prefix 91 and remainder 6745738932 Feb 18 21:53:16.102: ////GK/gk_rassrv_get_ingress_network: returning default ingress network = 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A1BCB50 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is US, and z_invianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A1BD030 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: No tech prefix Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: Alias not found Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: lrq array index 1B, lap 4A1C37F4 Feb 18 21:53:16.106: //005FE03F1900/005FE03F1900/GK/send_lrq: sent lrq - zonecount 1 Feb 18 21:53:16.130: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: local zone= US, remote zone= PSTN-WAN, call direction= 1, eptype= 67586 be_entry= 0 Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: returns proxied = 0 PSTN-WAN *Mar 1 00:10:49.991: ////GK/gk_rassrv_lrq: (916745738932) Tech-prefix match failed. *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: (916745738932) Matched zone-prefix 91 *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0 *Mar 1 00:10:49.999: ////GK/gk_rassrv_lrq: srcvia found gkname of source zone. looking up US in zone list *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: about to check the source side
Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India
Hi Roger, Thanks for replying. It adds the star by default when you put in the tech prefix eg 1#. Cheers Kev Roger Källberg roger.kallb...@cygate.se wrote: Hi Kevin, I'm a bit off here, cause GK isn't my strongest area, but shouldn't the line with the default tech-prefix look like this? gw-type-prefix 1# default-technology IE, no * after the # Maybe it's not it, but it's my 2 cent. Roger Källberg Consultant Cygate AB Eric Perssons väg 21, SE-217 62 MALMÖ Från: Kevin Hobson [kevin.hobson2...@ntlworld.com] Skickat: den 19 februari 2010 07:28 Till: o...@ipexpert.com; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Ämne: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Otto, Please see my config for the GK on the PSTN below: gatekeeper zone local PSTN-WAN ipexpert.com 10.100.1.1 zone remote HQ-RTR ipexpert.com 10.100.200.2 1719 zone remote US ipexpert.com 10.10.110.1 1719 zone prefix PSTN-WAN 34* zone prefix PSTN-WAN 91* gw-type-prefix 1#* default-technology no shutdown ! interface FastEthernet0/1 ip address 10.100.1.1 255.255.255.0 ip ospf network broadcast duplex full speed 100 h323-gateway voip interface h323-gateway voip id PSTN-WAN ipaddr 10.100.1.1 1719 h323-gateway voip h323-id pstn-gw h323-gateway voip bind srcaddr 10.100.1.1 h323-gateway voip tech-prefix 1# no shut It looks correct. It just seems that it is not going on to look to for a Default Techprefix which should then route it to the PSTN-WAN Zone. Please note my lab is a mixture of physical and virtual devices using a combination of GNS3 and Cisco routers. I will move the PSTN config to a physical device today when i get to the office just to rule out the virtual not being able to do this kind of thing. Thanks Kev -Original Message- From: o...@ipexpert.com [mailto:o...@ipexpert.com] Sent: 19 February 2011 04:12 To: Kevin Hobson; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Kevin, According to your hq debug, the call is being properly routed to the pstn remote zone, therefore your hq rtr configuration should be good. I would like to check your pstn wan gk configuration, would you please sent it? Thanks, Enviado desde mi BlackBerry de Movistar -Original Message- From: Kevin Hobson kevin.hobson2...@ntlworld.com Date: Thu, 18 Feb 2010 18:00:42 To: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India I have an issue with Lab5c where when i call India it just stops on the PSTN-WAN router at proxy on debug gatek main 10. After this the timer expires on the UCM and fails to complete. See below: HQ-RTR Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Tech-prefix match failed. Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Matched zone prefix 91 and remainder 6745738932 Feb 18 21:53:16.102: ////GK/gk_rassrv_get_ingress_network: returning default ingress network = 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A1BCB50 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is US, and z_invianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A1BD030 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: No tech prefix Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: Alias not found Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: lrq array index 1B, lap 4A1C37F4 Feb 18 21:53:16.106: //005FE03F1900/005FE03F1900/GK/send_lrq: sent lrq - zonecount 1 Feb 18 21:53:16.130: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: local zone= US, remote zone= PSTN-WAN, call direction= 1, eptype= 67586 be_entry= 0 Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: returns proxied = 0 PSTN-WAN *Mar 1 00:10:49.991: ////GK/gk_rassrv_lrq: (916745738932) Tech-prefix match failed. *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: (916745738932) Matched zone-prefix 91 *Mar 1 00:10:49.995: //
Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India
I think I had the same problem. This is to do with the dial-peer on the receiving gateway. You probably want to do a debug voip dialpeer on the receiving gateway to troubleshoot this. Thanks Kalyan From: kevin.hobson2...@ntlworld.com To: Roger Källberg roger.kallb...@cygate.se, o...@ipexpert.com o...@ipexpert.com, ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com, ccie_voice-boun...@onlinestudylist.com ccie_voice-boun...@onlinestudylist.com Date: 02/19/2010 12:02 PM Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Sent by: ccie_voice-boun...@onlinestudylist.com Hi Roger, Thanks for replying. It adds the star by default when you put in the tech prefix eg 1#. Cheers Kev Roger Källberg roger.kallb...@cygate.se wrote: Hi Kevin, I'm a bit off here, cause GK isn't my strongest area, but shouldn't the line with the default tech-prefix look like this? gw-type-prefix 1# default-technology IE, no * after the # Maybe it's not it, but it's my 2 cent. Roger Källberg Consultant Cygate AB Eric Perssons väg 21, SE-217 62 MALMÖ Från: Kevin Hobson [kevin.hobson2...@ntlworld.com] Skickat: den 19 februari 2010 07:28 Till: o...@ipexpert.com; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Ämne: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Otto, Please see my config for the GK on the PSTN below: gatekeeper zone local PSTN-WAN ipexpert.com 10.100.1.1 zone remote HQ-RTR ipexpert.com 10.100.200.2 1719 zone remote US ipexpert.com 10.10.110.1 1719 zone prefix PSTN-WAN 34* zone prefix PSTN-WAN 91* gw-type-prefix 1#* default-technology no shutdown ! interface FastEthernet0/1 ip address 10.100.1.1 255.255.255.0 ip ospf network broadcast duplex full speed 100 h323-gateway voip interface h323-gateway voip id PSTN-WAN ipaddr 10.100.1.1 1719 h323-gateway voip h323-id pstn-gw h323-gateway voip bind srcaddr 10.100.1.1 h323-gateway voip tech-prefix 1# no shut It looks correct. It just seems that it is not going on to look to for a Default Techprefix which should then route it to the PSTN-WAN Zone. Please note my lab is a mixture of physical and virtual devices using a combination of GNS3 and Cisco routers. I will move the PSTN config to a physical device today when i get to the office just to rule out the virtual not being able to do this kind of thing. Thanks Kev -Original Message- From: o...@ipexpert.com [mailto:o...@ipexpert.com] Sent: 19 February 2011 04:12 To: Kevin Hobson; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Kevin, According to your hq debug, the call is being properly routed to the pstn remote zone, therefore your hq rtr configuration should be good. I would like to check your pstn wan gk configuration, would you please sent it? Thanks, Enviado desde mi BlackBerry de Movistar -Original Message- From: Kevin Hobson kevin.hobson2...@ntlworld.com Date: Thu, 18 Feb 2010 18:00:42 To: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India I have an issue with Lab5c where when i call India it just stops on the PSTN-WAN router at proxy on debug gatek main 10. After this the timer expires on the UCM and fails to complete. See below: HQ-RTR Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Tech-prefix match failed. Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Matched zone prefix 91 and remainder 6745738932 Feb 18 21:53:16.102: ////GK/gk_rassrv_get_ingress_network: returning default ingress network = 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A1BCB50 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is US, and z_invianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A1BD030 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: No tech prefix Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: Alias not found Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: lrq array index 1B, lap 4A1C37F4 Feb 18 21:53:16.106: //005FE03F1900/005FE03F1900/GK/send_lrq: sent lrq - zonecount 1 Feb 18
Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India
Hi Kevin, You are right, configuration seems to be good, just make sure the alias is registered to the gk or that the destination number is reachable through the pstn-gw gateway, so check your incoming dial peer and that india phone is registered to the cme, which I suppose is your case, Let me know after you reconfigure you equipment, Thanks, On Fri, Feb 19, 2010 at 1:01 PM, iy...@nationwide.com wrote: I think I had the same problem. This is to do with the dial-peer on the receiving gateway. You probably want to do a debug voip dialpeer on the receiving gateway to troubleshoot this. Thanks Kalyan From: kevin.hobson2...@ntlworld.com To: Roger Källberg roger.kallb...@cygate.se, o...@ipexpert.com o...@ipexpert.com, ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com, ccie_voice-boun...@onlinestudylist.com ccie_voice-boun...@onlinestudylist.com Date: 02/19/2010 12:02 PM Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Sent by: ccie_voice-boun...@onlinestudylist.com -- Hi Roger, Thanks for replying. It adds the star by default when you put in the tech prefix eg 1#. Cheers Kev Roger Källberg roger.kallb...@cygate.se wrote: Hi Kevin, I'm a bit off here, cause GK isn't my strongest area, but shouldn't the line with the default tech-prefix look like this? gw-type-prefix 1# default-technology IE, no * after the # Maybe it's not it, but it's my 2 cent. Roger Källberg Consultant Cygate AB Eric Perssons väg 21, SE-217 62 MALMÖ Från: Kevin Hobson [kevin.hobson2...@ntlworld.com] Skickat: den 19 februari 2010 07:28 Till: o...@ipexpert.com; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Ämne: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Otto, Please see my config for the GK on the PSTN below: gatekeeper zone local PSTN-WAN ipexpert.com 10.100.1.1 zone remote HQ-RTR ipexpert.com 10.100.200.2 1719 zone remote US ipexpert.com 10.10.110.1 1719 zone prefix PSTN-WAN 34* zone prefix PSTN-WAN 91* gw-type-prefix 1#* default-technology no shutdown ! interface FastEthernet0/1 ip address 10.100.1.1 255.255.255.0 ip ospf network broadcast duplex full speed 100 h323-gateway voip interface h323-gateway voip id PSTN-WAN ipaddr 10.100.1.1 1719 h323-gateway voip h323-id pstn-gw h323-gateway voip bind srcaddr 10.100.1.1 h323-gateway voip tech-prefix 1# no shut It looks correct. It just seems that it is not going on to look to for a Default Techprefix which should then route it to the PSTN-WAN Zone. Please note my lab is a mixture of physical and virtual devices using a combination of GNS3 and Cisco routers. I will move the PSTN config to a physical device today when i get to the office just to rule out the virtual not being able to do this kind of thing. Thanks Kev -Original Message- From: o...@ipexpert.com [mailto:o...@ipexpert.com o...@ipexpert.com] Sent: 19 February 2011 04:12 To: Kevin Hobson; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Kevin, According to your hq debug, the call is being properly routed to the pstn remote zone, therefore your hq rtr configuration should be good. I would like to check your pstn wan gk configuration, would you please sent it? Thanks, Enviado desde mi BlackBerry de Movistar -Original Message- From: Kevin Hobson kevin.hobson2...@ntlworld.com Date: Thu, 18 Feb 2010 18:00:42 To: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India I have an issue with Lab5c where when i call India it just stops on the PSTN-WAN router at proxy on debug gatek main 10. After this the timer expires on the UCM and fails to complete. See below: HQ-RTR Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Tech-prefix match failed. Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Matched zone prefix 91 and remainder 6745738932 Feb 18 21:53:16.102: ////GK/gk_rassrv_get_ingress_network: returning default ingress network = 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A1BCB50 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is US, and z_invianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A1BD030 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 Feb 18 21:53:16.102
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Jeff, Do a debug gatekeeper main 10 on the gatekeeper and check/send the output when you make a call. It will tell you whats happening and if there is a routing failure at the gatekeeper. Also, take a look at this documentation http://www.cisco.com/en/US/docs/ios/voice/cubegk/configuration/guide/ve_book/ve_book.html , it details how to configure gatekeeper with CUBE and its a good read. -- Mustafa Jeff Price (jeffpric) wrote: Hi everyone, I’m having an issue with my gatekeeper. When calling from CUCM to GK to CME, the calls go through. I know this because I have shutdown the T1 controller and completed the calls. However, when calling from the CME to GK to CUCM, the calls do not go through. I have been analyzing the debug h225 asn1 output for an answer and I’m not finding one. The GK even sends an ACF, but shortly after CME sends a DRQ. I was figuring either a BW or codec/h245 issue, but I haven’t configured an CAC for the GK and it doesn’t seem to be a codec negotiation issue, because the calls wouldn’t go through from CUCM to CME via the GK. I have the Regions configured to use G729 on the CUCM side and the dial-peers to use g2729r8 on CME. I’m attaching the RAS output. If anyone wants some more information I’ll be happy to send it. The thing that is standing out to me the most is this in the DRQ message - terminationCause releaseCompleteCauseIE : '08028090'H. The only thing I found on google for it seems like it’s the standard DRQ cause IE. So I’m not finding anything worthwhile. Any help is appreciated. Thanks a lot. http://www.cisco.com/cisco/web/UK/images/emails/signaturetool/the_human_network_logo.jpg *Jeff Price** Network Consulting Engineer - Unified Communications Practice* * * jeffp...@cisco.com mailto:jeffp...@cisco.com Phone: *408-525-8293* Mobile: *408-204-4510* ** *Cisco Systems, Inc.* 170 West Tasman Drive, San Jose, CA 95134-1706 USA Cisco home page http://www.cisco.com/ http://www.cisco.com/cisco/web/UK/images/emails/signaturetool/welcome_to_human_network_lo.jpg http://www.cisco.com/global/EMEA/brand/signature/capital/green.gifThink before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Gatekeeper Issue
I'm looking through this as I'm sending. I also wanted to note that I set the Service Parameter BRQ Enable to True, because I noticed that the DRQs were coming shortly after the BRQ were sent by the CME. *Feb 20 03:18:10.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:10.457: ////GK/gk_handle_timers *Feb 20 03:18:10.457: ////GK/gk_handle_timers: managed timer expired 0x47620C08 *Feb 20 03:18:10.733: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:13.393: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.393: ////GK/gk_rassrv_arq: arqp=0x4A5F7A4C,crv=0x37, answerCall=0 *Feb 20 03:18:13.393: ////GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/gk_dns_query: No Name servers *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched tech-prefix 1# *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 *Feb 20 03:18:13.393: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A696CA4 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: matched zone is ZONE_01, an R1#d z_invianamelen=0 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A696CA4 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: matched zone is ZONE_01, and z_outvianamelen=0 *Feb 20 03:18:13.397: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 *Feb 20 03:18:13.421: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.421: ////GK/gk_rassrv_arq: arqp=0x4AD8C8B8,crv=0x8037, answerCall=1 *Feb 20 03:18:13.421: //95E2E82B812F/95E2E82B8131/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC *Feb 20 03:18:13.465: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.469: ////GK/gk_rassrv_brq: state = 0xF *Feb 20 03:18:13.469: ////GK/gk_rassrv_brq: brqp=0x4A6F94A8, crv=0x8037, bandWidth=160 R1# R1# *Feb 20 03:18:22.781: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:22.781: ////GK/gk_rassrv_brq: state = 0xF *Feb 20 03:18:22.781: ////GK/gk_rassrv_brq: brqp=0x4A6F94A8, crv=0x37, bandWidth=0 *Feb 20 03:18:22.785: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:22.805: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:22.805: ////GK/gk_rassrv_arq: arqp=0x4AB97164,crv=0x8038, answerCall=1 *Feb 20 03:18:22.805: //95E2E82B812F/95E2E82B8131/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC R1# *Feb 20 03:18:25.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:25.457: ////GK/gk_handle_timers *Feb 20 03:18:25.457: ////GK/gk_handle_timers: managed timer expired 0x47620C08 R1# *Feb 20 03:18:27.825: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:27.829: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:33.965: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:34.381: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:40.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:40.457: ////GK/gk_handle_timers *Feb 20 03:18:40.457: ////GK/gk_handle_timers: managed timer expired 0x47620C08 Thanks, Jeff -Original Message- From: Mustafa [mailto:afat...@verizon.net] Sent: Friday, February 19, 2010 6:09 PM To: Jeff Price (jeffpric) Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue Jeff, Do a debug gatekeeper main 10 on the gatekeeper and check/send the output when you make a call. It will tell you whats happening and if there is a routing failure at the gatekeeper. Also, take a look at this documentation http://www.cisco.com/en/US/docs/ios/voice/cubegk/configuration/guide/ve_ book/ve_book.html , it details how to configure gatekeeper with CUBE and its a good read. -- Mustafa Jeff Price (jeffpric) wrote: Hi everyone, I'm having an issue with my gatekeeper. When calling from CUCM to GK to CME, the calls go through. I know this because I have shutdown the T1 controller
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Mustafa, Do I need a XCODER on CME? Region is configured to use G729 and so is the dial-peer on CME. The call goes through successfully when calling from CUCM to CME site, so that leads me to believe the XCODER is necessary? The call never goes through. No ringing, no busy, nothing. As far as I can tell, the call goes through the GK logic of trying both TRUNKS (SUB then PUB) and then falls back to the PSTN dial-peer I've configured and the call is completed successfully through the PSTN. Jeff -Original Message- From: Mustafa [mailto:afat...@verizon.net] Sent: Friday, February 19, 2010 6:28 PM To: Jeff Price (jeffpric); CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue GK seems to be routing the call. Do you get a busy tone when the call is unsuccessful? Have you configured an xcoder anyway on CME? -- Mustafa Jeff Price (jeffpric) wrote: I'm looking through this as I'm sending. I also wanted to note that I set the Service Parameter BRQ Enable to True, because I noticed that the DRQs were coming shortly after the BRQ were sent by the CME. *Feb 20 03:18:10.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:10.457: ////GK/gk_handle_timers *Feb 20 03:18:10.457: ////GK/gk_handle_timers: managed timer expired 0x47620C08 *Feb 20 03:18:10.733: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:13.393: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.393: ////GK/gk_rassrv_arq: arqp=0x4A5F7A4C,crv=0x37, answerCall=0 *Feb 20 03:18:13.393: ////GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/gk_dns_query: No Name servers *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched tech-prefix 1# *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 *Feb 20 03:18:13.393: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A696CA4 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: matched zone is ZONE_01, an R1#d z_invianamelen=0 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A696CA4 *Feb 20 03:18:13.393: //95E2E82B812F/95E2E82B8131/GK/rassrv_arq_select_viazone: matched zone is ZONE_01, and z_outvianamelen=0 *Feb 20 03:18:13.397: ////GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1 *Feb 20 03:18:13.421: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.421: ////GK/gk_rassrv_arq: arqp=0x4AD8C8B8,crv=0x8037, answerCall=1 *Feb 20 03:18:13.421: //95E2E82B812F/95E2E82B8131/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC *Feb 20 03:18:13.465: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.469: ////GK/gk_rassrv_brq: state = 0xF *Feb 20 03:18:13.469: ////GK/gk_rassrv_brq: brqp=0x4A6F94A8, crv=0x8037, bandWidth=160 R1# R1# *Feb 20 03:18:22.781: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:22.781: ////GK/gk_rassrv_brq: state = 0xF *Feb 20 03:18:22.781: ////GK/gk_rassrv_brq: brqp=0x4A6F94A8, crv=0x37, bandWidth=0 *Feb 20 03:18:22.785: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:22.805: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:22.805: ////GK/gk_rassrv_arq: arqp=0x4AB97164,crv=0x8038, answerCall=1 *Feb 20 03:18:22.805: //95E2E82B812F/95E2E82B8131/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC R1# *Feb 20 03:18:25.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:25.457: ////GK/gk_handle_timers *Feb 20 03:18:25.457: ////GK/gk_handle_timers: managed timer expired 0x47620C08 R1# *Feb 20 03:18:27.825: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:27.829: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:33.965: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:34.381: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:40.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:40.457: //
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Here is the output of command debug gatekeeper call 10: *Feb 20 03:38:14.913: ////GK/gk_call_new: src_endptp=0x4ABCA7A8, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=61, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:14.913: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:14.913: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4ABCA7A8 *Feb 20 03:38:14.937: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:14.937: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:15.005: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:15.005: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:24.397: ////GK/gk_call_find_crv: endptp=0x4ABCA7A8, crv=61: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is SEP *Feb 20 03:38:24.397: ////GK/gk_call_clear_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x801, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C R1# *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C01, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.425: ////GK/gk_call_find_dstendpt: NOT_FOUND *Feb 20 03:38:24.425: ////GK/gk_call_new: src_endptp=0x47621FB0, dst_endptp=0x4ABFA848, src_pxp=0x0, dst_pxp=0x0, bw=1280, crv=32830, whichcrv=0x2, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:24.425: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:24.429: ////GK/gk_call_new: checking for default (CLI) carrier for dep endpt 0x4ABFA848 R1# *Feb 20 03:38:29.449: ////GK/gk_call_clear_crv: endptp=0x4ABFA848, crv=32830: *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x800, c_resbw1 0, resbw2 1280, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A57164C *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x6C00, c_resbw1 0, resbw2 0, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: ////GK/gk_call_clear_crv: endptp=0x4ABCA7A8, crv=61: R1# *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is SEP *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 The gk_call_find_endpts: NOT_FOUND line is leading me to believe something that I was noticed on the debug gatekeeper main 10 command: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 The pattern I've configured on CUCM is expecting to receive in the form 17752011001. This output almost makes it seem like only 7752011001 is being sent, is this correct? I'm going to try to add another pattern without the 1 so that I can test this. Jeff -Original Message- From: Mustafa [mailto:afat...@verizon.net] Sent: Friday, February 19, 2010 6:28 PM To: Jeff Price (jeffpric); CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue GK seems to be routing the call. Do you get a busy tone when the call is unsuccessful? Have you configured an xcoder anyway on CME? -- Mustafa Jeff Price (jeffpric) wrote: I'm looking through this as I'm sending. I also wanted to note that I set the Service Parameter BRQ Enable to True, because I noticed that the DRQs were coming shortly after the BRQ were sent by the CME. *Feb 20 03:18:10.457: ////GK/gk_process: got a TIMER event *Feb 20 03:18:10.457: ////GK/gk_handle_timers *Feb 20 03:18:10.457: ////GK/gk_handle_timers: managed timer expired 0x47620C08 *Feb 20 03:18:10.733: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup R1# *Feb 20 03:18:13.393: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 20 03:18:13.393: ////GK/gk_rassrv_arq: arqp=0x4A5F7A4C,crv=0x37, answerCall=0 *Feb 20 03:18:13.393
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Mustafa, So I figured out why. CUCM was unable to find the number and that's why it couldn't route. The reason why CUCM could find the number is...a stupid mistake. I simply forgot to set the DDI to Predot. Now this is working. It always the little things... Thanks Mustafa for your help. Jeff -Original Message- From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Jeff Price (jeffpric) Sent: Friday, February 19, 2010 6:38 PM To: CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue Here is the output of command debug gatekeeper call 10: *Feb 20 03:38:14.913: ////GK/gk_call_new: src_endptp=0x4ABCA7A8, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=61, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:14.913: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:14.913: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4ABCA7A8 *Feb 20 03:38:14.937: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:14.937: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:15.005: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:15.005: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:24.397: ////GK/gk_call_find_crv: endptp=0x4ABCA7A8, crv=61: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is SEP *Feb 20 03:38:24.397: ////GK/gk_call_clear_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x801, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C R1# *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C01, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.425: ////GK/gk_call_find_dstendpt: NOT_FOUND *Feb 20 03:38:24.425: ////GK/gk_call_new: src_endptp=0x47621FB0, dst_endptp=0x4ABFA848, src_pxp=0x0, dst_pxp=0x0, bw=1280, crv=32830, whichcrv=0x2, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:24.425: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:24.429: ////GK/gk_call_new: checking for default (CLI) carrier for dep endpt 0x4ABFA848 R1# *Feb 20 03:38:29.449: ////GK/gk_call_clear_crv: endptp=0x4ABFA848, crv=32830: *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x800, c_resbw1 0, resbw2 1280, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A57164C *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x6C00, c_resbw1 0, resbw2 0, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: ////GK/gk_call_clear_crv: endptp=0x4ABCA7A8, crv=61: R1# *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is SEP *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 The gk_call_find_endpts: NOT_FOUND line is leading me to believe something that I was noticed on the debug gatekeeper main 10 command: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 The pattern I've configured on CUCM is expecting to receive in the form 17752011001. This output almost makes it seem like only 7752011001 is being sent, is this correct? I'm going to try to add another pattern without the 1 so that I can test this. Jeff -Original Message- From: Mustafa [mailto:afat...@verizon.net] Sent: Friday, February 19, 2010 6:28 PM To: Jeff Price (jeffpric); CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue GK seems to be routing the call. Do you get a busy tone when the call is unsuccessful? Have you configured an xcoder anyway on CME? -- Mustafa Jeff Price (jeffpric) wrote: I'm looking through this as I'm sending. I also wanted to note that I set the Service Parameter BRQ Enable to True, because I noticed that the DRQs were coming shortly after the BRQ were sent by the CME. *Feb 20 03:18:10.457
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Hi Mustafa, The direction is from CME to CUCM. Both are configured for G.729 and I've confirmed a call goes through and uses G729 both ways. That's definitely odd for the bandwidth to say that. I don't really have an answer, but the call is using G729 as configured. Thanks again. Jeff -Original Message- From: Mustafa [mailto:afat...@verizon.net] Sent: Friday, February 19, 2010 6:49 PM To: Jeff Price (jeffpric) Cc: CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue whats the direction of call? Previous debug has bandwidth 160, which is 16k for g729 and this one is showing bandwidth 1280 which is 128k for g711. So this call leg debug is showing is g711 is being requested somwhere. -- Mustafa Jeff Price (jeffpric) wrote: Here is the output of command debug gatekeeper call 10: *Feb 20 03:38:14.913: ////GK/gk_call_new: src_endptp=0x4ABCA7A8, dst_endptp=0x0, src_pxp=0x0, dst_pxp=0x0, bw=160, crv=61, whichcrv=0x1, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:14.913: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:14.913: ////GK/gk_call_new: checking for default (CLI) carrier for sep endpt 0x4ABCA7A8 *Feb 20 03:38:14.937: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:14.937: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:15.005: ////GK/gk_call_find_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:15.005: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is DEP R1# *Feb 20 03:38:24.397: ////GK/gk_call_find_crv: endptp=0x4ABCA7A8, crv=61: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_find_crv: crv is SEP *Feb 20 03:38:24.397: ////GK/gk_call_clear_crv: endptp=0x4A6F20B0, crv=32829: *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x801, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C R1# *Feb 20 03:38:24.397: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C01, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:24.425: ////GK/gk_call_find_dstendpt: NOT_FOUND *Feb 20 03:38:24.425: ////GK/gk_call_new: src_endptp=0x47621FB0, dst_endptp=0x4ABFA848, src_pxp=0x0, dst_pxp=0x0, bw=1280, crv=32830, whichcrv=0x2, circuit=0x0, capacity=0x0, ret_callpp=0x492D8D78 *Feb 20 03:38:24.425: ////GK/gk_call_find_endpts: NOT_FOUND *Feb 20 03:38:24.429: ////GK/gk_call_new: checking for default (CLI) carrier for dep endpt 0x4ABFA848 R1# *Feb 20 03:38:29.449: ////GK/gk_call_clear_crv: endptp=0x4ABFA848, crv=32830: *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is DEP *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x800, c_resbw1 0, resbw2 1280, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A57164C *Feb 20 03:38:29.449: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x6C00, c_resbw1 0, resbw2 0, c_reszp1 0x4761C1A4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: ////GK/gk_call_clear_crv: endptp=0x4ABCA7A8, crv=61: R1# *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: crv is SEP *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_clear_crv: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: callp=4A35B91C *Feb 20 03:38:29.453: //620E1FC68141/620EBBEE8143/GK/gk_call_delete: c_callstate 0x7C00, c_resbw1 0, resbw2 0, c_reszp1 0x4A696CA4, c_reszp2 0x4A696CA4 The gk_call_find_endpts: NOT_FOUND line is leading me to believe something that I was noticed on the debug gatekeeper main 10 command: //95E2E82B812F/95E2E82B8131/GK/rassrv_get_addrinfo: (1#17752011001) Matched zone prefix 1 and remainder 7752011001 The pattern I've configured on CUCM is expecting to receive in the form 17752011001. This output almost makes it seem like only 7752011001 is being sent, is this correct? I'm going to try to add another pattern without the 1 so that I can test this. Jeff -Original Message- From: Mustafa [mailto:afat...@verizon.net] Sent: Friday, February 19, 2010 6:28 PM To: Jeff Price (jeffpric); CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue GK seems to be routing the call. Do you get a busy tone when the call is unsuccessful? Have you configured an xcoder
[OSL | CCIE_Voice] Gatekeeper Issue
Hi Jeff, Please chk the Tech prefix on the CUCM , If its set to 1# , then u need to send 1 # along with the no from CME remove it at the GW with incoming allowed nos or use TP. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Gatekeeper Issue
Hi Kavi, Thanks. I already had this configured. I appreciate your help. Now the GK functionality is working like a charm. I just forgot the Predot DDI in the CUCM Translation Pattern. Jeff From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of kavi ten Sent: Friday, February 19, 2010 8:12 PM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Gatekeeper Issue Hi Jeff, Please chk the Tech prefix on the CUCM , If its set to 1# , then u need to send 1 # along with the no from CME remove it at the GW with incoming allowed nos or use TP. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India
Hi Kevin, According to your hq debug, the call is being properly routed to the pstn remote zone, therefore your hq rtr configuration should be good. I would like to check your pstn wan gk configuration, would you please sent it? Thanks, Enviado desde mi BlackBerry de Movistar -Original Message- From: Kevin Hobson kevin.hobson2...@ntlworld.com Date: Thu, 18 Feb 2010 18:00:42 To: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India I have an issue with Lab5c where when i call India it just stops on the PSTN-WAN router at proxy on debug gatek main 10. After this the timer expires on the UCM and fails to complete. See below: HQ-RTR Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Tech-prefix match failed. Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Matched zone prefix 91 and remainder 6745738932 Feb 18 21:53:16.102: ////GK/gk_rassrv_get_ingress_network: returning default ingress network = 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A1BCB50 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is US, and z_invianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A1BD030 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: No tech prefix Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: Alias not found Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: lrq array index 1B, lap 4A1C37F4 Feb 18 21:53:16.106: //005FE03F1900/005FE03F1900/GK/send_lrq: sent lrq - zonecount 1 Feb 18 21:53:16.130: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: local zone= US, remote zone= PSTN-WAN, call direction= 1, eptype= 67586 be_entry= 0 Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: returns proxied = 0 PSTN-WAN *Mar 1 00:10:49.991: ////GK/gk_rassrv_lrq: (916745738932) Tech-prefix match failed. *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: (916745738932) Matched zone-prefix 91 *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0 *Mar 1 00:10:49.999: ////GK/gk_rassrv_lrq: srcvia found gkname of source zone. looking up US in zone list *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: about to check the source side, src_zonep=0x663AD438 *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: matched zone is US *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq and z_invianamelen=0 *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: about to check the destination side, zonep=0x663ACD4C *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq:matched zone is PSTN-WAN *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq and z_outvianamelen=0 *Mar 1 00:10:50.003: ////GK/gk_zone_get_proxy_usage: local zone= PSTN-WAN, remote zone= US, call direction= 0, eptype= 67650 be_entry= 0 *Mar 1 00:10:50.003: ////GK/gk_zone_get_proxy_usage: returns proxied = 0 Any assistance much appreciated. Thanks Kev -Original Message- From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of ccie_voice-requ...@onlinestudylist.com Sent: 18 February 2010 17:00 To: ccie_voice@onlinestudylist.com Subject: CCIE_Voice Digest, Vol 48, Issue 101 Send CCIE_Voice mailing list submissions to ccie_voice@onlinestudylist.com To subscribe or unsubscribe via the World Wide Web, visit http://onlinestudylist.com/mailman/listinfo/ccie_voice or, via email, send a message with subject or body 'help' to ccie_voice-requ...@onlinestudylist.com You can reach the person managing the list at ccie_voice-ow...@onlinestudylist.com When replying, please edit your Subject line so it is more specific than Re: Contents of CCIE_Voice digest... Today's Topics: 1. CUE in lab 11A (iy...@nationwide.com) 2. Re: CUE in lab 11A (o...@ipexpert.com) 3. Re: FXO Inbound w/ MGCP (Roger K?llberg) 4. UCCX Scripting (Roger Henderson) 5. Re: UCCX Scripting (Brian Valentine) 6. Re: UCCX Scripting (Pulos, Greg
Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India
Hi Otto, Please see my config for the GK on the PSTN below: gatekeeper zone local PSTN-WAN ipexpert.com 10.100.1.1 zone remote HQ-RTR ipexpert.com 10.100.200.2 1719 zone remote US ipexpert.com 10.10.110.1 1719 zone prefix PSTN-WAN 34* zone prefix PSTN-WAN 91* gw-type-prefix 1#* default-technology no shutdown ! interface FastEthernet0/1 ip address 10.100.1.1 255.255.255.0 ip ospf network broadcast duplex full speed 100 h323-gateway voip interface h323-gateway voip id PSTN-WAN ipaddr 10.100.1.1 1719 h323-gateway voip h323-id pstn-gw h323-gateway voip bind srcaddr 10.100.1.1 h323-gateway voip tech-prefix 1# no shut It looks correct. It just seems that it is not going on to look to for a Default Techprefix which should then route it to the PSTN-WAN Zone. Please note my lab is a mixture of physical and virtual devices using a combination of GNS3 and Cisco routers. I will move the PSTN config to a physical device today when i get to the office just to rule out the virtual not being able to do this kind of thing. Thanks Kev -Original Message- From: o...@ipexpert.com [mailto:o...@ipexpert.com] Sent: 19 February 2011 04:12 To: Kevin Hobson; ccie_voice-boun...@onlinestudylist.com; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India Hi Kevin, According to your hq debug, the call is being properly routed to the pstn remote zone, therefore your hq rtr configuration should be good. I would like to check your pstn wan gk configuration, would you please sent it? Thanks, Enviado desde mi BlackBerry de Movistar -Original Message- From: Kevin Hobson kevin.hobson2...@ntlworld.com Date: Thu, 18 Feb 2010 18:00:42 To: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Gatekeeper Issue when calling India I have an issue with Lab5c where when i call India it just stops on the PSTN-WAN router at proxy on debug gatek main 10. After this the timer expires on the UCM and fails to complete. See below: HQ-RTR Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Tech-prefix match failed. Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: (916745738932) Matched zone prefix 91 and remainder 6745738932 Feb 18 21:53:16.102: ////GK/gk_rassrv_get_ingress_network: returning default ingress network = 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4A1BCB50 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is US, and z_invianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4A1BD030 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: No tech prefix Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_get_addrinfo: Alias not found Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 Feb 18 21:53:16.102: //005FE03F1900/005FE03F1900/GK/send_lrq: lrq array index 1B, lap 4A1C37F4 Feb 18 21:53:16.106: //005FE03F1900/005FE03F1900/GK/send_lrq: sent lrq - zonecount 1 Feb 18 21:53:16.130: ////GK/gk_process: QUEUE_EVENT (minor 0) wakeup Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: local zone= US, remote zone= PSTN-WAN, call direction= 1, eptype= 67586 be_entry= 0 Feb 18 21:53:16.130: //005FE03F1900/005FE03F1900/GK/gk_zone_get_proxy_usage: returns proxied = 0 PSTN-WAN *Mar 1 00:10:49.991: ////GK/gk_rassrv_lrq: (916745738932) Tech-prefix match failed. *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: (916745738932) Matched zone-prefix 91 *Mar 1 00:10:49.995: ////GK/gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0 *Mar 1 00:10:49.999: ////GK/gk_rassrv_lrq: srcvia found gkname of source zone. looking up US in zone list *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: about to check the source side, src_zonep=0x663AD438 *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: matched zone is US *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq and z_invianamelen=0 *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq: about to check the destination side, zonep=0x663ACD4C *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq:matched zone is PSTN-WAN *Mar 1 00:10:50.003: ////GK/gk_rassrv_lrq and z_outvianamelen=0 *Mar 1 00:10:50.003: ////GK/gk_zone_get_proxy_usage: local zone
[OSL | CCIE_Voice] gatekeeper issue
I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com 172.9.100.1 zone remote PSTN-WAN ipexpert.com 10.9.200.2 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech-prefix match failed. *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:35:53.535: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is HQ-RTR, and z_invianamelen=0 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:35:53.535: rassrv_get_addrinfo: No tech prefix *Feb 6 23:35:53.535: rassrv_get_addrinfo: Alias not found *Feb 6 23:35:53.535: rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN *Feb 6 23:35:53.535: send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 *Feb 6 23:35:53.535: send_lrq: lrq array index 17, lap 46EC60CC *Feb 6 23:35:53.539: send_lrq: sent lrq - zonecount 1 *Feb 6 23:35:53.539: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: local zone= HQ-RTR, remote zone= PSTN-WAN, call direction= 1, eptype= 133122 be_entry= 0 *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: returns proxied = 0 *Feb 6 23:35:58.871: gk_process: got a TIMER event *Feb 6 23:35:58.871: gk_handle_timers *Feb 6 23:35:58.871: gk_handle_timers: managed timer expired 0x452D4450 *Feb 6 23:36:05.271: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_rassrv_arq: arqp=0x46E902E0, crv=0xF, answerCall=0 *Feb 6 23:36:05.279: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:36:05.279: gk_dns_query: No Name servers *Feb 6 23:36:05.279: rassrv_get_addrinfo: (0113313293003) Tech-prefix match failed. *Feb 6 23:36:05.279: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:36:05.279: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:36:05.279: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:36:05.279: rassrv_arq_select_viazone: matched zone is HQ-RTR, and z_invianamelen=0 *Feb 6 23:36:05.279: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:36:05.279: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:36:05.279: rassrv_get_addrinfo: No tech prefix *Feb 6 23:36:05.279: rassrv_get_addrinfo: Alias not found *Feb 6 23:36:05.279: rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN *Feb 6 23:36:05.279: send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 *Feb 6 23:36:05.279: send_lrq: lrq array index 18, lap 46EC6114 *Feb 6 23:36:05.283: send_lrq: sent lrq - zonecount 1 *Feb 6 23:36:05.283: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.287: gk_zone_get_proxy_usage: local zone= HQ-RTR, remote zone= PSTN-WAN, call direction= 1, eptype= 133122 be_entry= 0 *Feb 6 23:36:05.287: gk_zone_get_proxy_usage: returns proxied = 0 *Feb 6 23:36:10.739: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:13.871: gk_process: got a TIMER event *Feb 6 23:36:13.871: gk_handle_timers *Feb 6 23:36:13.871: gk_handle_timers: managed timer expired 0x452D4450 *Feb 6 23:36:14.211: gk_process: QUEUE_EVENT (minor 0) wakeup Mrugesh Patel Berbee, a CDW Company Network Voice Engineer 8725 West Higgins Road
Re: [OSL | CCIE_Voice] gatekeeper issue
Mark, I reverted the HQ gateway configs using the browser REVERT button and the loopback comes up with 172.9.100.1 ip address. Regardless, I changed my third octet and reloaded but still the same issue. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 6:59 PM To: Patel, Mrugesh Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Not in front of a computer but I believe that the 3rd octet of your local zone (and thus where your GK is expecting a LCF from the PSTN GK) is incorrect. I beleive it should be 172.9.200.1 not .100.1. Mark Snow Sr Technical Instructor IPexpert, Inc. Sent from my iPhone On Feb 6, 2008, at 7:40 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com 172.9.100.1 zone remote PSTN-WAN ipexpert.com 10.9.200.2 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech-prefix match failed. *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:35:53.535: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is HQ-RTR, and z_invianamelen=0 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:35:53.535: rassrv_get_addrinfo: No tech prefix *Feb 6 23:35:53.535: rassrv_get_addrinfo: Alias not found *Feb 6 23:35:53.535: rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN *Feb 6 23:35:53.535: send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 *Feb 6 23:35:53.535: send_lrq: lrq array index 17, lap 46EC60CC *Feb 6 23:35:53.539: send_lrq: sent lrq - zonecount 1 *Feb 6 23:35:53.539: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: local zone= HQ-RTR, remote zone= PSTN-WAN, call direction= 1, eptype= 133122 be_entry= 0 *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: returns proxied = 0 *Feb 6 23:35:58.871: gk_process: got a TIMER event *Feb 6 23:35:58.871: gk_handle_timers *Feb 6 23:35:58.871: gk_handle_timers: managed timer expired 0x452D4450 *Feb 6 23:36:05.271: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_rassrv_arq: arqp=0x46E902E0, crv=0xF, answerCall=0 *Feb 6 23:36:05.279: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:36:05.279: gk_dns_query: No Name servers *Feb 6 23:36:05.279: rassrv_get_addrinfo: (0113313293003) Tech-prefix match failed. *Feb 6 23:36:05.279: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:36:05.279: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:36:05.279: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160
Re: [OSL | CCIE_Voice] gatekeeper issue
I am thinking it may be something with the PSTN-WAN. I will wait for Mark of Vik to comment though. Usually I fly through this part of the gatekeeper config, but today this just blew my confidence away. From: Chad Stachowicz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 7:56 PM To: Patel, Mrugesh Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Patel, it matched the right zone, sure its not a PSTN-WAN configuration error? gateway config is correct. On 2/6/08, Patel, Mrugesh [EMAIL PROTECTED] wrote: Mark, I reverted the HQ gateway configs using the browser REVERT button and the loopback comes up with 172.9.100.1 http://172.9.100.1/ ip address. Regardless, I changed my third octet and reloaded but still the same issue. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 6:59 PM To: Patel, Mrugesh Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Not in front of a computer but I believe that the 3rd octet of your local zone (and thus where your GK is expecting a LCF from the PSTN GK) is incorrect. I beleive it should be 172.9.200.1 http://172.9.200.1/ not .100.1. Mark Snow Sr Technical Instructor IPexpert, Inc. Sent from my iPhone On Feb 6, 2008, at 7:40 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com http://ipexpert.com/ 172.9.100.1 http://172.9.100.1/ zone remote PSTN-WAN ipexpert.com http://ipexpert.com/ 10.9.200.2 http://10.9.200.2/ 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech-prefix match failed. *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:35:53.535: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is HQ-RTR, and z_invianamelen=0 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:35:53.535: rassrv_get_addrinfo: No tech prefix *Feb 6 23:35:53.535: rassrv_get_addrinfo: Alias not found *Feb 6 23:35:53.535: rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN *Feb 6 23:35:53.535: send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 *Feb 6 23:35:53.535: send_lrq: lrq array index 17, lap 46EC60CC *Feb 6 23:35:53.539: send_lrq: sent lrq - zonecount 1 *Feb 6 23:35:53.539: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: local zone= HQ-RTR, remote zone= PSTN-WAN, call direction= 1, eptype= 133122 be_entry= 0 *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: returns proxied = 0 *Feb 6 23:35:58.871: gk_process: got a TIMER event *Feb 6 23:35:58.871: gk_handle_timers *Feb 6 23:35:58.871: gk_handle_timers: managed timer expired 0x452D4450 *Feb 6 23:36:05.271: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_process: QUEUE_EVENT (minor 0) wakeup
Re: [OSL | CCIE_Voice] gatekeeper issue
Hey Guys - keep in mind (if you read the PL forums you might now - and if not - start :) - because that is where we update you on all the new stuff you can do on our hardware) - You all have access to the PSTN Router - so you can troubleshoot! :) (you don't have it in the actual IE lab - but hey - this is study :-). Telnet to 10.xx.200.2 and login with the password ipexpert You ONLY have Privilege Level 1 - however - we have allowed Priv 1 to execute the following commands on every PSTN router: term mon sh debug sh isdn status debug isdn q931 debug ras debug gatekeeper main 10 debug h225 asn1 Cheers, Mark Snow CCIE #14073 (Voice, Security) CCSI #31583 Senior Technical Instructor - IPexpert, Inc. A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.309.413.4097 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE RS Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. On Feb 6, 2008, at 9:08 PM, Chad Stachowicz wrote: Patel, I had the same thing happen to me with a 6608 PSTN cononection last week, and it was a PSTN-WAN config error... don't worry, your gatekeeper config is correct dude ;) On Feb 6, 2008 5:58 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am thinking it may be something with the PSTN-WAN. I will wait for Mark of Vik to comment though. Usually I fly through this part of the gatekeeper config, but today this just blew my confidence away. From: Chad Stachowicz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 7:56 PM To: Patel, Mrugesh Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Patel, it matched the right zone, sure its not a PSTN-WAN configuration error? gateway config is correct. On 2/6/08, Patel, Mrugesh [EMAIL PROTECTED] wrote: Mark, I reverted the HQ gateway configs using the browser REVERT button and the loopback comes up with 172.9.100.1 ip address. Regardless, I changed my third octet and reloaded but still the same issue. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 6:59 PM To: Patel, Mrugesh Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Not in front of a computer but I believe that the 3rd octet of your local zone (and thus where your GK is expecting a LCF from the PSTN GK) is incorrect. I beleive it should be 172.9.200.1 not .100.1. Mark Snow Sr Technical Instructor IPexpert, Inc. Sent from my iPhone On Feb 6, 2008, at 7:40 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com 172.9.100.1 zone remote PSTN-WAN ipexpert.com 10.9.200.2 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech- prefix match failed. *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:35:53.535: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is HQ- RTR, and z_invianamelen=0 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:35:53.535: rassrv_get_addrinfo: No tech prefix *Feb 6 23:35:53.535: rassrv_get_addrinfo: Alias not found *Feb 6 23:35:53.535: rassrv_put_remote_zones_from_zone_list: zone
Re: [OSL | CCIE_Voice] gatekeeper issue
Hey Chad - curious - what was the error that ended up being acknowledged on the PSTN router and on what pod? Like to know to check it out on other pods as well ... Thanks! Mark Snow CCIE #14073 (Voice, Security) CCSI #31583 Senior Technical Instructor - IPexpert, Inc. A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.309.413.4097 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE RS Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. On Feb 6, 2008, at 9:08 PM, Chad Stachowicz wrote: Patel, I had the same thing happen to me with a 6608 PSTN cononection last week, and it was a PSTN-WAN config error... don't worry, your gatekeeper config is correct dude ;) On Feb 6, 2008 5:58 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am thinking it may be something with the PSTN-WAN. I will wait for Mark of Vik to comment though. Usually I fly through this part of the gatekeeper config, but today this just blew my confidence away. From: Chad Stachowicz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 7:56 PM To: Patel, Mrugesh Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Patel, it matched the right zone, sure its not a PSTN-WAN configuration error? gateway config is correct. On 2/6/08, Patel, Mrugesh [EMAIL PROTECTED] wrote: Mark, I reverted the HQ gateway configs using the browser REVERT button and the loopback comes up with 172.9.100.1 ip address. Regardless, I changed my third octet and reloaded but still the same issue. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 6:59 PM To: Patel, Mrugesh Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Not in front of a computer but I believe that the 3rd octet of your local zone (and thus where your GK is expecting a LCF from the PSTN GK) is incorrect. I beleive it should be 172.9.200.1 not .100.1. Mark Snow Sr Technical Instructor IPexpert, Inc. Sent from my iPhone On Feb 6, 2008, at 7:40 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com 172.9.100.1 zone remote PSTN-WAN ipexpert.com 10.9.200.2 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech- prefix match failed. *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:35:53.535: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is HQ- RTR, and z_invianamelen=0 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:35:53.535: rassrv_get_addrinfo: No tech prefix *Feb 6 23:35:53.535: rassrv_get_addrinfo: Alias not found *Feb 6 23:35:53.535: rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN *Feb 6 23:35:53.535: send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 *Feb 6 23:35:53.535: send_lrq: lrq array index 17, lap 46EC60CC *Feb 6 23:35:53.539: send_lrq: sent lrq - zonecount 1 *Feb 6 23:35:53.539: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: local zone= HQ-RTR, remote zone= PSTN-WAN, call direction= 1, eptype= 133122 be_entry= 0 *Feb 6 23:35:53.543
Re: [OSL | CCIE_Voice] gatekeeper issue
One can even console to it with their proctor lab username and password from the terminal server. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 9:06 PM To: Chad Stachowicz Cc: Patel, Mrugesh; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Hey Guys - keep in mind (if you read the PL forums you might now - and if not - start :) - because that is where we update you on all the new stuff you can do on our hardware) - You all have access to the PSTN Router - so you can troubleshoot! :) (you don't have it in the actual IE lab - but hey - this is study :-). Telnet to 10.xx.200.2 and login with the password ipexpert You ONLY have Privilege Level 1 - however - we have allowed Priv 1 to execute the following commands on every PSTN router: term mon sh debug sh isdn status debug isdn q931 debug ras debug gatekeeper main 10 debug h225 asn1 Cheers, Mark Snow CCIE #14073 (Voice, Security) CCSI #31583 Senior Technical Instructor - IPexpert, Inc. A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.309.413.4097 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE RS Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. On Feb 6, 2008, at 9:08 PM, Chad Stachowicz wrote: Patel, I had the same thing happen to me with a 6608 PSTN cononection last week, and it was a PSTN-WAN config error... don't worry, your gatekeeper config is correct dude ;) On Feb 6, 2008 5:58 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am thinking it may be something with the PSTN-WAN. I will wait for Mark of Vik to comment though. Usually I fly through this part of the gatekeeper config, but today this just blew my confidence away. From: Chad Stachowicz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 7:56 PM To: Patel, Mrugesh Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Patel, it matched the right zone, sure its not a PSTN-WAN configuration error? gateway config is correct. On 2/6/08, Patel, Mrugesh [EMAIL PROTECTED] wrote: Mark, I reverted the HQ gateway configs using the browser REVERT button and the loopback comes up with 172.9.100.1 http://172.9.100.1/ ip address. Regardless, I changed my third octet and reloaded but still the same issue. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 6:59 PM To: Patel, Mrugesh Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Not in front of a computer but I believe that the 3rd octet of your local zone (and thus where your GK is expecting a LCF from the PSTN GK) is incorrect. I beleive it should be 172.9.200.1 http://172.9.200.1/ not .100.1. Mark Snow Sr Technical Instructor IPexpert, Inc. Sent from my iPhone On Feb 6, 2008, at 7:40 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com http://ipexpert.com/ 172.9.100.1 http://172.9.100.1/ zone remote PSTN-WAN ipexpert.com http://ipexpert.com/ 10.9.200.2 http://10.9.200.2/ 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech-prefix match failed. *Feb 6
Re: [OSL | CCIE_Voice] gatekeeper issue
That was the proper IP - sorry - wasn't in front of my computer before - try the call again this time debugging ras from the PSTN router - to see if you get the LCF. I saw the debug Gatekeeper main 10 below - however I didn't see the results of the 'debug ras' - can you retry and include that from your HQ router? Just as a (hopefully helpful) note - I often times in classes see students that think the PSTN GK is rejecting their call - when in fact upon running a debug ras they see the LCF from the PSTN GK indicating that it is working properly - but find later the problem to be with their incoming BR2 Pots trunk (be it PRI or R2). Cheers, Mark Snow CCIE #14073 (Voice, Security) CCSI #31583 Senior Technical Instructor - IPexpert, Inc. A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.309.413.4097 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE RS Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. On Feb 6, 2008, at 8:10 PM, Patel, Mrugesh wrote: Mark, I reverted the HQ gateway configs using the browser REVERT button and the loopback comes up with 172.9.100.1 ip address. Regardless, I changed my third octet and reloaded but still the same issue. From: Mark Snow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 6:59 PM To: Patel, Mrugesh Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] gatekeeper issue Not in front of a computer but I believe that the 3rd octet of your local zone (and thus where your GK is expecting a LCF from the PSTN GK) is incorrect. I beleive it should be 172.9.200.1 not .100.1. Mark Snow Sr Technical Instructor IPexpert, Inc. Sent from my iPhone On Feb 6, 2008, at 7:40 PM, Patel, Mrugesh [EMAIL PROTECTED] wrote: I am unable to route calls to the PSTN-WAN remote gatekeeper. Here is the trace. Any ideas? I place a call from HQ and it just waits and finally gives me a busy. My configs gatekeeper zone local HQ-RTR ipexpert.com 172.9.100.1 zone remote PSTN-WAN ipexpert.com 10.9.200.2 1719 no zone subnet HQ-RTR default enable zone subnet HQ-RTR 10.9.200.20/32 enable zone subnet HQ-RTR 10.9.200.21/32 enable zone prefix PSTN-WAN 011* gw-type-prefix 1#* default-technology bandwidth remote 144 no shutdown P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR# P19-HQ-RTR#config t Enter configuration commands, one per line. End with CNTL/Z. P19-HQ-RTR(config)#gateke P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011 *Feb 6 23:35:43.871: gk_process: got a TIMER event *Feb 6 23:35:43.871: gk_handle_timers *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4630 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4600 *Feb 6 23:35:43.871: gk_handle_timers: managed timer expired 0x452D4450 * P19-HQ-RTR(config-gk)#zone prefix PSTN-WAN 011* P19-HQ-RTR(config-gk)# *Feb 6 23:35:53.535: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.535: gk_rassrv_arq: arqp=0x4594C140, crv=0x4, answerCall=0 *Feb 6 23:35:53.535: gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC *Feb 6 23:35:53.535: gk_dns_query: No Name servers *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Tech- prefix match failed. *Feb 6 23:35:53.535: rassrv_get_addrinfo: (0113313293003) Matched zone prefix 011 and remainder 3313293003 *Feb 6 23:35:53.535: gk_rassrv_get_ingress_network: returning default ingress network = 1 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46EC4160 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is HQ- RTR, and z_invianamelen=0 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45918198 *Feb 6 23:35:53.535: rassrv_arq_select_viazone: matched zone is PSTN-WAN, and z_outvianamelen=0 *Feb 6 23:35:53.535: rassrv_get_addrinfo: No tech prefix *Feb 6 23:35:53.535: rassrv_get_addrinfo: Alias not found *Feb 6 23:35:53.535: rassrv_put_remote_zones_from_zone_list: zone PSTN-WAN *Feb 6 23:35:53.535: send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1 *Feb 6 23:35:53.535: send_lrq: lrq array index 17, lap 46EC60CC *Feb 6 23:35:53.539: send_lrq: sent lrq - zonecount 1 *Feb 6 23:35:53.539: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: local zone= HQ-RTR, remote zone= PSTN-WAN, call direction= 1, eptype= 133122 be_entry= 0 *Feb 6 23:35:53.543: gk_zone_get_proxy_usage: returns proxied = 0 *Feb 6 23:35:58.871: gk_process: got a TIMER event *Feb 6 23:35:58.871: gk_handle_timers *Feb 6 23:35:58.871: gk_handle_timers: managed timer expired 0x452D4450 *Feb 6 23:36:05.271: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_process: QUEUE_EVENT (minor 0) wakeup *Feb 6 23:36:05.279: gk_rassrv_arq: arqp
