Hello, for me i can call from HQ to br2 but can not call from br2 to hq
i always get a unknwn number tone What do you think is missing thanks Below is the output when calling from br2 to hq Also when i removed the bandwidth session 16, it goes through but you wont hear the callers'seech and gets disconnected after a while with a reorder tone HQ-RTR# Dec 22 01:40:12.129: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Dec 22 01:40:12.129: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48DAF694,crv=0x3C, answerCall=0 Dec 22 01:40:12.129: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_sep_arq: ARQ Didn't use GK_AAA_PROC Dec 22 01:40:12.129: //C7A4073280DD/C7A53F8280DF/GK/gk_dns_query: No Name servers Dec 22 01:40:12.129: //C7A4073280DD/C7A53F8280DF/GK/rassrv_get_addrinfo: (1#12123945001) Matched tech-prefix 1# Dec 22 01:40:12.129: //C7A4073280DD/C7A53F8280DF/GK/rassrv_get_addrinfo: (1#12123945001) unresolved zone prefix, using source zone HQ Dec 22 01:40:12.129: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 3 Dec 22 01:40:12.129: //C7A4073280DD/C7A53F8280DF/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x48C88C44 Dec 22 01:40:12.129: //C7A4073280DD/C7A53F8280DF/GK/rassrv_arq_select_viazone: matched zone is HQ, and z_outvian HQ-RTR#amelen=0 Dec 22 01:40:12.129: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 3 Dec 22 01:40:12.153: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Dec 22 01:40:12.153: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48DAF694,crv=0x803C, answerCall=1 Dec 22 01:40:12.153: //C7A4073280DD/C7A53F8280DF/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC Dec 22 01:40:12.177: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Dec 22 01:40:12.177: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48D9B850,crv=0x803D, answerCall=1 Dec 22 01:40:12.177: //C7A4073280DD/C7A53F8280DF/GK/gk_rassrv_dep_arq: ARQ Didn't use GK_AAA_PROC Dec 22 01:40:12.189: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup Dec 22 01:40:12.233: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: got a TIMER event Thanks for the anticipated support On Tue, Nov 17, 2009 at 12:35 AM, Vik Malhi <vma...@ipexpert.com> wrote: > Q4.4 is dealing with registration to GK. > > The dial-peer is created in the call routing section: > > On the BR2-RTR: > > *voice translation-rule 15 > rule 1 /^5...$/ /1#1212394\0/ > rule 2 /^1...$/ /1#1617863\0/ > ! > voice translation-profile GK-OUT > translate called 15 > > ! > dial-peer voice 15 voip > destination-pattern [15]...$ > session target ras > no vad > dtmf-relay h245-alphanumberic > translation-profile out GK-OUT > * > -- > Vik Malhi – CCIE #13890 > Senior Technical Instructor - IPexpert, Inc. > > Telephone: +1.810.326.1444 > Fax: +1.810.454.0130 > Mailto: *vma...@ipexpert.com > > * > Join our free online support and peer group communities: > *http://www.IPexpert.com/communities <http://www.ipexpert.com/communities> > *IPexpert - The Global Leader in Self-Study, Classroom-Based, > Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE > R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and > CCIE Storage Lab Certifications. > > > > > > > > ------------------------------ > *From: *Nara Shikamaru <shikam...@kagadis.com> > *Date: *Mon, 16 Nov 2009 15:44:45 -0700 > *To: *"Kumar, Narinder" <narinder.ku...@uxcg.com.au> > *Cc: *OSL Group <ccie_voice@onlinestudylist.com> > *Subject: *Re: [OSL | CCIE_Voice] ILT Lab 1 Question 4.4 - No default > technology prefix?! > > > This config is puzzling. There should at least be a dial peer on BR2 > pointing to the gatekeep with *session target ras*. The only dial-peers > that seem to be pointing traffic to the 1 and 5 patterns are; > > dial-peer voice 15 voip > destination-pattern [15]...$ > voice-class codec 1 > session protocol sipv2 > session target ipv4:10.10.210.11 > incoming called-number . > no vad > ! > dial-peer voice 16 voip > preference 1 > destination-pattern [15]...$ > voice-class codec 1 > session protocol sipv2 > session target ipv4:10.10.210.10 > no vad > > > > On Mon, Nov 16, 2009 at 3:11 PM, Kumar, Narinder < > narinder.ku...@uxcg.com.au> wrote: > > I don’t remember what is the exact requirements of Lab 4.4. > > Are you sending any tech prefix from ur gateway’s when they are registering > with the gatekeeper ? > > Not sure what will happen if the gateways are registering with gatekeeper > with a different tech prefix and GK is using the default tech prefix , which > one takes priority or what happens. > > I need to read up on the gatekeepers again. > > > *From:* ccie_voice-boun...@onlinestudylist.com [ > mailto:ccie_voice-boun...@onlinestudylist.com<ccie_voice-boun...@onlinestudylist.com>] > *On Behalf Of *Nara Shikamaru > *Sent:* Tuesday, 17 November 2009 8:59 AM > *To:* OSL Group > *Subject:* [OSL | CCIE_Voice] ILT Lab 1 Question 4.4 - No default > technology prefix?! > > > > I'm very confused. In this question, we are told very explicitly in > bulltet 3 that we are not allowed to use the default technology prefix > sytnax. But, in the final configuration file for the gatekeeper it's > actually used; > > > *gatekeeper > zone local US ipexpert.com <http://ipexpert.com/> > zone local Spain ipexpert.com <http://ipexpert.com/> > zone remote PSTN-WAN ipexpert.com <http://ipexpert.com/> 10.10.100.2 > 1719 > > zone prefix Spain 34* > zone prefix PSTN-WAN 91* > gw-type-prefix 1#* default-technology > no shutdown > endpoint resource-threshold > endpoint max-calls h323id gk-trunk_2 1 > * > > > > > > > Can someone help me understand? Am I seeing this correctly? > > > > -- > -Shikamaru > > ------------------------------ > CONFIDENTIALITY - The information contained in this electronic mail > message is confidential and is intended solely for the addressee(s). If you > are not an authorised recipient of this message please contact UXC Getronics > Australia immediately by reply email and destroy/delete this message from > your computer. Any unauthorised form of reproduction of this message, or > part thereof, is strictly prohibited. > DISCLAIMER - Unless specifically indicated otherwise, the views and > opinions expressed in this email are those of the sender and not UXC > Getronics Australia. While we endeavour to protect our network from computer > viruses, UXC Getronics Australia does not warrant that this email or any > attachments are free of viruses or any other defects or errors. It is the > duty of the recipient to virus scan and otherwise test any information > contained in this email before loading onto any computer system. > > > > > -- > -Shikamaru > > ------------------------------ > _______________________________________________ > 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 > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
