[OSL | CCIE_Voice] Codec and CAC section
hi folks, can anyone share experience on what to check on this section , I got 0 for few attempt. Here is what I did : UCM = - service parameter : no "G722" and "ILBC" - Enterprise parameter G711 intra, G729 inter - Region : HQ SB SC, HQ-HQ : G711 , SB-SB G711, SC-SC : g711 (rest relation : G729) and assign tp DP - Location : HQ and SC : mandatory , assign to DP - MRGL HQ --> MRG--> MTP from HQ & same for SC , assign to DP router HQ and SC = - dspfarm profile 3 mtp codec pass-through codec g729r8 rsvp maximum sessions software 4 (as they asked 4 session of g729) associate application SCCP - interface Serial0/0/0.1 point-to-point frame-relay interface-dlci 102 ip rsvp bandwidth 112 verification = - call hq to hq, sb sb : g711, inter site phone and GW : g729 - sh ip rsvp reservation : 40 k (ring) , and 24 k (connect) question: - did i miss something critical that cause the mark to be 0 ?___ 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] not able to login cupc
thanks Bill! i will check and update if it works... for cue i see that loopback 0 is haivng /32 ip so that service module not accepting ip if we use /24 ip then it will worki will test it and confirm you... thanks for all your support! On Sun, Jun 23, 2013 at 3:04 PM, Bill Lake wrote: > Run the CUPS system troubleshooter and it can be very helpful > > If that shows all good try restarting CUPS server > > Third issue is find the fix on Cisco's website at (might want to learn to > find this page) > > > http://www.cisco.com/en/US/products/sw/custcosw/ps1846/products_tech_note09186a008088cff0.shtml > > Change the parm to T so it will show up > > No routing to CUE, not configured correctly, bad password, reboot of cue, > cue being a pain, OK you get the idea, you have to eliminate each and every > reason it might not work, also sometimes just restarting CUE when you know > it is right will help. > > Post your config but usually it would look something like this (this is > from memory so please if a command is slightly off fix it) > > interface loopback 0 > ip ospf network point-to-point > > int service-engine 0/0 > ip unnumbered loopback 0 > service-module ip address 255.255.255.255 > service-module ip default-gateway > no shut > > ip route 255.255.255.255 service-engine 0/0 > > Your IP's will very as will the module type. > > Good luck > > > > On Sat, Jun 22, 2013 at 10:31 PM, Amit Sharma wrote: > >> guys. >> i am trying to login cupcbut not successful.. >> showing login issue? >> how can fix it? >> >> >> >> second i am not be able to see cucm end users in cupc for desktop >> control... >> what could be the issue? >> >> third issue is that in ccm end user i dont have option to add ipcc >> extnesion... >> how can see that option to add ipcc extension...for one button login...? >> >> >> >> fourth point is that i configure cue with loopback 1 ip but after >> config...not seen register cti port and cti route point why? >> >> if using lo 0 it is not accepting under service modulehow can use lo0 >> ipr range for service module? >> >> >> -- >> Thanks & Regard's >> Amit Sharma >> >> >> ___ >> 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 >> > > -- Thanks & Regard's Amit Sharma ___ 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 is unable to reach SiteB under Call Forward UnRegister
Calls work when he is not in SRST so 3... must be sending to CUCM to be processed and set to phones at site B. They are registered and work but when unregistered they fail to work. If we are going on this little snippet of his GK config we might need the entire thing and those on the GW's to figure out why this call is not working. On Sun, Jun 23, 2013 at 5:30 AM, Somphol Boonjing wrote: > Hi Hesham, > > If the problem is on the gatekeeper, it could be as simple as the zone > prefix not configured to point to CUCM for the pattern "3..." > > Given that in normal situation, the zone prefix would be pointing "SBGW" > either dynamically or statically. > > The configure with static zone prefix set would look similar to this. > > gatekeeeper > ... > ... > gw-type-prefix 1#* default-technology > zone prefix THEZONE 3... gw-priority 100 SBGW > zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK > ... > ... > > If your CUCM & SBGW happens to be in the different zones, that is a > different matter. Looking at a configuration guide for "zone prefix" > command, I don't think it is possible for a zone prefix to point to two > different local zones. (See: > http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_z1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1002271 > ) > > So, in essence, I doubt that this would work. > > gatekeeeper > ... > ... > gw-type-prefix 1#* default-technology > zone prefix SBZONE 3... gw-priority 100 SBGW > zone prefix CUCMZONE 3... gw-priority 10 CUCMTRUNK > ... > ... > > Regards, > --Somphol. > > > On Sun, Jun 23, 2013 at 6:45 PM, Hesham Abdelkereem < > heshamcentr...@gmail.com> wrote: > >> Hi Somphol, >> >> Of course all your sequence of ideas definitely make sense. >> However, I did exactly all that >> I made the Route List for CFUR is very specific to HQ Gateway and not >> SLRG. >> and Tried to change the Inbound Calls in the trunk and changed the CSS to >> INTERNAL and still didn't work, >> >> yes I am looking into the debug command that will show me the gatekeeper >> call flow. >> I have been a long time never worked with that. >> >> Thanks for your ideas, >> >> I will keep you and the forum posted if I got any updates, >> >> Thanks, >> Hesham >> >> >> On 23 June 2013 01:40, Somphol Boonjing wrote: >> >>> Hi Hesham, >>> >>> I have a few ideas. I want to remove a few things out of the equation, >>> first try to set codec for all inter-region to G711. Second, if you are >>> using Local Route Group (LRG), replace it with a more straightforward >>> settings -- i.e. point the RL directly to HQ gateway in your case for >>> relevant route pattern. We can deal with them later on once we >>> understand this case to the bone. >>> >>> There are two call legs. The first call leg is from SC PH1 to reach >>> x3001 via a H323 Trunk on CUCM -- the Trunk with gatekeeper control. The >>> call should be directed to the gatekeeper who in turn should be routing it >>> to the H323 Trunk on CUCM. The H323 Trunk should have significant digits >>> set to 4 and a CSS that can reach x3001. >>> >>> Upon hitting x3001, CUCM will discover that the number is forwarded to >>> 9723033001. Assuming that you have set the CSS for CFUR on x3001 >>> correctly, that will match a Router Pattern that route the call toward HQ >>> Gateway.This is a second call leg.(If you use the LRG, at this >>> point, the LRG for the incoming H323 Trunk will cause the call to route to >>> the wrong RG.) >>> >>> Once the second call leg is established, then CUCM will tell the two >>> parities to open the RTP channel directly to each other (i.e. between the >>> CME and the HQ Gateway.) (Well, sort of, if you have MTP required check >>> on the H323 Trunk, then an MTP will be involved.) >>> >>> You problem could be on either one of this. While I believe that since >>> you can make a call from HQ PH1 to x3001 successfully, the problem may not >>> be in the 2nd leg, I don't entirely want to rule out the CSS, the >>> Significant digits as well as the fact that HQ PH1 and the incoming H323 >>> Trunk will be more than likely belong to a different Device Pool & Region. >>> >>> I think "debug gatekeeper main 10" on the gatekeeper would help. >>> >>> On the H323 CUCM Trunk, RTMT Real Time monitoring with "Detailed Debug" >>> turn on would help you see whether the H323 Trunk has the right CSS to >>> reach x3001. >>> >>> Hope this gives you some idea to work on this case. >>> >>> Regards, >>> --Somphol. >>> >>> >>> >>> >>> >>> On Sun, Jun 23, 2013 at 5:27 PM, Somphol Boonjing wrote: >>> Hi Hesham, Thanks for the detail explanation and well thanks for sharing the case. I find it very intriguing. I'm working on some idea, but for now, I just want to forward your reply to the group, in case anyone else can help too. --Somphol On Sun, Jun 23, 2013 at 4:44 PM, Hesham Abdelkereem < heshamcentr...@gmail.com> wrote: > Hi Somphol, > > I have
Re: [OSL | CCIE_Voice] not able to login cupc
Run the CUPS system troubleshooter and it can be very helpful If that shows all good try restarting CUPS server Third issue is find the fix on Cisco's website at (might want to learn to find this page) http://www.cisco.com/en/US/products/sw/custcosw/ps1846/products_tech_note09186a008088cff0.shtml Change the parm to T so it will show up No routing to CUE, not configured correctly, bad password, reboot of cue, cue being a pain, OK you get the idea, you have to eliminate each and every reason it might not work, also sometimes just restarting CUE when you know it is right will help. Post your config but usually it would look something like this (this is from memory so please if a command is slightly off fix it) interface loopback 0 ip ospf network point-to-point int service-engine 0/0 ip unnumbered loopback 0 service-module ip address 255.255.255.255 service-module ip default-gateway no shut ip route 255.255.255.255 service-engine 0/0 Your IP's will very as will the module type. Good luck On Sat, Jun 22, 2013 at 10:31 PM, Amit Sharma wrote: > guys. > i am trying to login cupcbut not successful.. > showing login issue? > how can fix it? > > > > second i am not be able to see cucm end users in cupc for desktop > control... > what could be the issue? > > third issue is that in ccm end user i dont have option to add ipcc > extnesion... > how can see that option to add ipcc extension...for one button login...? > > > > fourth point is that i configure cue with loopback 1 ip but after > config...not seen register cti port and cti route point why? > > if using lo 0 it is not accepting under service modulehow can use lo0 > ipr range for service module? > > > -- > Thanks & Regard's > Amit Sharma > > > ___ > 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 is unable to reach SiteB under Call Forward UnRegister
Sorry, I assume wrongly that SBGW will ever take the call for "3...". Your normal path is for both "2..." and "3..." to be pointing to CUCMTRUNK only. Given that both SBGW and CUCMTRUNK are registered to the same zone, it would be necessary to exclude SBGW from ever getting the call destined to "2..." or "3...". gw-type-prefix 1#* default-technology zone prefix THEZONE 3... gw-priority 0 SBGW zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK zone prefix THEZONE 2... gw-priority 0 SBGW zone prefix THEZONE 2... gw-priority 10 CUCMTRUNK Sorry for the confusion. Even if you don't have "gw-priority", when SBGW is unreachable, it should not cause the problem and call should be sent correctly to CUCMTRUNK. Then, it is less likely that the problem would be in the gatekeeper call leg, unless you use some sort of tech-prefix in addition to zone prefix. Regards, --Somphol On Sun, Jun 23, 2013 at 8:43 PM, Somphol Boonjing wrote: > Hi Hesham, > > Essentially, the gw-priority is to advise the gatekeeper to choose SBGW > over CUCMTRUNK. The higher the number, the higher the priority. Without > this it will distribute the call to "3XXX" to both CUCMTRUNK and SBGW in a > round robin fashion. > > If you give higher priority to SBGW, then call will be routed to SBGW > unless it is not available. > > > gw-type-prefix 1#* default-technology > zone prefix THEZONE 3... gw-priority 100 SBGW > zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK > > I'm fairly new to gatekeeper myself, so it would be great if you can lab > it up and see if I am wildly off the mark. > > Regards, > --Somphol. > > > > On Sun, Jun 23, 2013 at 8:37 PM, Hesham Abdelkereem < > heshamcentr...@gmail.com> wrote: > >> Hi Somphol, >> >> HQ & SB are in the same zone >> and i don't understand >> >> zone prefix THEZONE 3... gw-priority 100 SBGW >> >> I think I should disregard it as they are int he same zone >> It's all just the CUCM Trunk and has both 2XXX and 3XXX >> I think that could make it work >> >> Thank you very much for ur great input >> I will test it and let u know >> >> Thank you very much for ur great efforts. >> >> On Jun 23, 2013, at 3:30 AM, Somphol Boonjing wrote: >> >> Hi Hesham, >> >> If the problem is on the gatekeeper, it could be as simple as the zone >> prefix not configured to point to CUCM for the pattern "3..." >> >> Given that in normal situation, the zone prefix would be pointing "SBGW" >> either dynamically or statically. >> >> The configure with static zone prefix set would look similar to this. >> >> gatekeeeper >> ... >> ... >> gw-type-prefix 1#* default-technology >> zone prefix THEZONE 3... gw-priority 100 SBGW >> zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK >> ... >> ... >> >> If your CUCM & SBGW happens to be in the different zones, that is a >> different matter. Looking at a configuration guide for "zone prefix" >> command, I don't think it is possible for a zone prefix to point to two >> different local zones. (See: >> http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_z1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1002271 >> ) >> >> So, in essence, I doubt that this would work. >> >> gatekeeeper >> ... >> ... >> gw-type-prefix 1#* default-technology >> zone prefix SBZONE 3... gw-priority 100 SBGW >> zone prefix CUCMZONE 3... gw-priority 10 CUCMTRUNK >> ... >> ... >> >> Regards, >> --Somphol. >> >> >> On Sun, Jun 23, 2013 at 6:45 PM, Hesham Abdelkereem < >> heshamcentr...@gmail.com> wrote: >> >>> Hi Somphol, >>> >>> Of course all your sequence of ideas definitely make sense. >>> However, I did exactly all that >>> I made the Route List for CFUR is very specific to HQ Gateway and not >>> SLRG. >>> and Tried to change the Inbound Calls in the trunk and changed the CSS >>> to INTERNAL and still didn't work, >>> >>> yes I am looking into the debug command that will show me the gatekeeper >>> call flow. >>> I have been a long time never worked with that. >>> >>> Thanks for your ideas, >>> >>> I will keep you and the forum posted if I got any updates, >>> >>> Thanks, >>> Hesham >>> >>> >>> On 23 June 2013 01:40, Somphol Boonjing wrote: >>> Hi Hesham, I have a few ideas. I want to remove a few things out of the equation, first try to set codec for all inter-region to G711. Second, if you are using Local Route Group (LRG), replace it with a more straightforward settings -- i.e. point the RL directly to HQ gateway in your case for relevant route pattern. We can deal with them later on once we understand this case to the bone. There are two call legs. The first call leg is from SC PH1 to reach x3001 via a H323 Trunk on CUCM -- the Trunk with gatekeeper control. The call should be directed to the gatekeeper who in turn should be routing it to the H323 Trunk on CUCM. The H323 Trunk should have significant digits set to 4 and a CSS that can reach x3001. Upon hitting x3001, CUCM will discover that the number is forwa
Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
Hi Hesham, Essentially, the gw-priority is to advise the gatekeeper to choose SBGW over CUCMTRUNK. The higher the number, the higher the priority. Without this it will distribute the call to "3XXX" to both CUCMTRUNK and SBGW in a round robin fashion. If you give higher priority to SBGW, then call will be routed to SBGW unless it is not available. gw-type-prefix 1#* default-technology zone prefix THEZONE 3... gw-priority 100 SBGW zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK I'm fairly new to gatekeeper myself, so it would be great if you can lab it up and see if I am wildly off the mark. Regards, --Somphol. On Sun, Jun 23, 2013 at 8:37 PM, Hesham Abdelkereem < heshamcentr...@gmail.com> wrote: > Hi Somphol, > > HQ & SB are in the same zone > and i don't understand > > zone prefix THEZONE 3... gw-priority 100 SBGW > > I think I should disregard it as they are int he same zone > It's all just the CUCM Trunk and has both 2XXX and 3XXX > I think that could make it work > > Thank you very much for ur great input > I will test it and let u know > > Thank you very much for ur great efforts. > > On Jun 23, 2013, at 3:30 AM, Somphol Boonjing wrote: > > Hi Hesham, > > If the problem is on the gatekeeper, it could be as simple as the zone > prefix not configured to point to CUCM for the pattern "3..." > > Given that in normal situation, the zone prefix would be pointing "SBGW" > either dynamically or statically. > > The configure with static zone prefix set would look similar to this. > > gatekeeeper > ... > ... > gw-type-prefix 1#* default-technology > zone prefix THEZONE 3... gw-priority 100 SBGW > zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK > ... > ... > > If your CUCM & SBGW happens to be in the different zones, that is a > different matter. Looking at a configuration guide for "zone prefix" > command, I don't think it is possible for a zone prefix to point to two > different local zones. (See: > http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_z1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1002271 > ) > > So, in essence, I doubt that this would work. > > gatekeeeper > ... > ... > gw-type-prefix 1#* default-technology > zone prefix SBZONE 3... gw-priority 100 SBGW > zone prefix CUCMZONE 3... gw-priority 10 CUCMTRUNK > ... > ... > > Regards, > --Somphol. > > > On Sun, Jun 23, 2013 at 6:45 PM, Hesham Abdelkereem < > heshamcentr...@gmail.com> wrote: > >> Hi Somphol, >> >> Of course all your sequence of ideas definitely make sense. >> However, I did exactly all that >> I made the Route List for CFUR is very specific to HQ Gateway and not >> SLRG. >> and Tried to change the Inbound Calls in the trunk and changed the CSS to >> INTERNAL and still didn't work, >> >> yes I am looking into the debug command that will show me the gatekeeper >> call flow. >> I have been a long time never worked with that. >> >> Thanks for your ideas, >> >> I will keep you and the forum posted if I got any updates, >> >> Thanks, >> Hesham >> >> >> On 23 June 2013 01:40, Somphol Boonjing wrote: >> >>> Hi Hesham, >>> >>> I have a few ideas. I want to remove a few things out of the equation, >>> first try to set codec for all inter-region to G711. Second, if you are >>> using Local Route Group (LRG), replace it with a more straightforward >>> settings -- i.e. point the RL directly to HQ gateway in your case for >>> relevant route pattern. We can deal with them later on once we >>> understand this case to the bone. >>> >>> There are two call legs. The first call leg is from SC PH1 to reach >>> x3001 via a H323 Trunk on CUCM -- the Trunk with gatekeeper control. The >>> call should be directed to the gatekeeper who in turn should be routing it >>> to the H323 Trunk on CUCM. The H323 Trunk should have significant digits >>> set to 4 and a CSS that can reach x3001. >>> >>> Upon hitting x3001, CUCM will discover that the number is forwarded to >>> 9723033001. Assuming that you have set the CSS for CFUR on x3001 >>> correctly, that will match a Router Pattern that route the call toward HQ >>> Gateway.This is a second call leg.(If you use the LRG, at this >>> point, the LRG for the incoming H323 Trunk will cause the call to route to >>> the wrong RG.) >>> >>> Once the second call leg is established, then CUCM will tell the two >>> parities to open the RTP channel directly to each other (i.e. between the >>> CME and the HQ Gateway.) (Well, sort of, if you have MTP required check >>> on the H323 Trunk, then an MTP will be involved.) >>> >>> You problem could be on either one of this. While I believe that since >>> you can make a call from HQ PH1 to x3001 successfully, the problem may not >>> be in the 2nd leg, I don't entirely want to rule out the CSS, the >>> Significant digits as well as the fact that HQ PH1 and the incoming H323 >>> Trunk will be more than likely belong to a different Device Pool & Region. >>> >>> I think "debug gatekeeper main 10" on the gatekeeper would help. >>> >>> On t
Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
Hi Hesham, If the problem is on the gatekeeper, it could be as simple as the zone prefix not configured to point to CUCM for the pattern "3..." Given that in normal situation, the zone prefix would be pointing "SBGW" either dynamically or statically. The configure with static zone prefix set would look similar to this. gatekeeeper ... ... gw-type-prefix 1#* default-technology zone prefix THEZONE 3... gw-priority 100 SBGW zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK ... ... If your CUCM & SBGW happens to be in the different zones, that is a different matter. Looking at a configuration guide for "zone prefix" command, I don't think it is possible for a zone prefix to point to two different local zones. (See: http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_z1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1002271 ) So, in essence, I doubt that this would work. gatekeeeper ... ... gw-type-prefix 1#* default-technology zone prefix SBZONE 3... gw-priority 100 SBGW zone prefix CUCMZONE 3... gw-priority 10 CUCMTRUNK ... ... Regards, --Somphol. On Sun, Jun 23, 2013 at 6:45 PM, Hesham Abdelkereem < heshamcentr...@gmail.com> wrote: > Hi Somphol, > > Of course all your sequence of ideas definitely make sense. > However, I did exactly all that > I made the Route List for CFUR is very specific to HQ Gateway and not SLRG. > and Tried to change the Inbound Calls in the trunk and changed the CSS to > INTERNAL and still didn't work, > > yes I am looking into the debug command that will show me the gatekeeper > call flow. > I have been a long time never worked with that. > > Thanks for your ideas, > > I will keep you and the forum posted if I got any updates, > > Thanks, > Hesham > > > On 23 June 2013 01:40, Somphol Boonjing wrote: > >> Hi Hesham, >> >> I have a few ideas. I want to remove a few things out of the equation, >> first try to set codec for all inter-region to G711. Second, if you are >> using Local Route Group (LRG), replace it with a more straightforward >> settings -- i.e. point the RL directly to HQ gateway in your case for >> relevant route pattern. We can deal with them later on once we >> understand this case to the bone. >> >> There are two call legs. The first call leg is from SC PH1 to reach >> x3001 via a H323 Trunk on CUCM -- the Trunk with gatekeeper control. The >> call should be directed to the gatekeeper who in turn should be routing it >> to the H323 Trunk on CUCM. The H323 Trunk should have significant digits >> set to 4 and a CSS that can reach x3001. >> >> Upon hitting x3001, CUCM will discover that the number is forwarded to >> 9723033001. Assuming that you have set the CSS for CFUR on x3001 >> correctly, that will match a Router Pattern that route the call toward HQ >> Gateway.This is a second call leg.(If you use the LRG, at this >> point, the LRG for the incoming H323 Trunk will cause the call to route to >> the wrong RG.) >> >> Once the second call leg is established, then CUCM will tell the two >> parities to open the RTP channel directly to each other (i.e. between the >> CME and the HQ Gateway.) (Well, sort of, if you have MTP required check >> on the H323 Trunk, then an MTP will be involved.) >> >> You problem could be on either one of this. While I believe that since >> you can make a call from HQ PH1 to x3001 successfully, the problem may not >> be in the 2nd leg, I don't entirely want to rule out the CSS, the >> Significant digits as well as the fact that HQ PH1 and the incoming H323 >> Trunk will be more than likely belong to a different Device Pool & Region. >> >> I think "debug gatekeeper main 10" on the gatekeeper would help. >> >> On the H323 CUCM Trunk, RTMT Real Time monitoring with "Detailed Debug" >> turn on would help you see whether the H323 Trunk has the right CSS to >> reach x3001. >> >> Hope this gives you some idea to work on this case. >> >> Regards, >> --Somphol. >> >> >> >> >> >> On Sun, Jun 23, 2013 at 5:27 PM, Somphol Boonjing wrote: >> >>> Hi Hesham, >>> >>> Thanks for the detail explanation and well thanks for sharing the case. >>> I find it very intriguing. >>> >>> I'm working on some idea, but for now, I just want to forward your reply >>> to the group, in case anyone else can help too. >>> >>> >>> --Somphol >>> >>> >>> On Sun, Jun 23, 2013 at 4:44 PM, Hesham Abdelkereem < >>> heshamcentr...@gmail.com> wrote: >>> Hi Somphol, I have to give you details as much as I can for better assistance not to tackle some of the information. Ok let me tell you the call flow In my scenario HQ and SB are registered to CUCM and SC is a CME (SC is connected with HQ & SB via Gatekeeper) I want to make sure that in case of SB WAN Failure HQ/SC phones are able to call Siteb phone using 4 digits in the event of wan failue.When you call from HQ phone calls should be routed through HQ gateway. When you call from SC Phones calls should be routed through the GK and then
Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
Hi Somphol, HQ & SB are in the same zone and i don't understand > zone prefix THEZONE 3... gw-priority 100 SBGW I think I should disregard it as they are int he same zone It's all just the CUCM Trunk and has both 2XXX and 3XXX I think that could make it work Thank you very much for ur great input I will test it and let u know Thank you very much for ur great efforts. On Jun 23, 2013, at 3:30 AM, Somphol Boonjing wrote: > Hi Hesham, > > If the problem is on the gatekeeper, it could be as simple as the zone prefix > not configured to point to CUCM for the pattern "3..." > > Given that in normal situation, the zone prefix would be pointing "SBGW" > either dynamically or statically. > > The configure with static zone prefix set would look similar to this. > > gatekeeeper > ... > ... > gw-type-prefix 1#* default-technology > zone prefix THEZONE 3... gw-priority 100 SBGW > zone prefix THEZONE 3... gw-priority 10 CUCMTRUNK > ... > ... > > If your CUCM & SBGW happens to be in the different zones, that is a different > matter. Looking at a configuration guide for "zone prefix" command, I don't > think it is possible for a zone prefix to point to two different local zones. > (See: > http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_z1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1002271) > > So, in essence, I doubt that this would work. > > gatekeeeper > ... > ... > gw-type-prefix 1#* default-technology > zone prefix SBZONE 3... gw-priority 100 SBGW > zone prefix CUCMZONE 3... gw-priority 10 CUCMTRUNK > ... > ... > > Regards, > --Somphol. > > > On Sun, Jun 23, 2013 at 6:45 PM, Hesham Abdelkereem > wrote: > Hi Somphol, > > Of course all your sequence of ideas definitely make sense. > However, I did exactly all that > I made the Route List for CFUR is very specific to HQ Gateway and not SLRG. > and Tried to change the Inbound Calls in the trunk and changed the CSS to > INTERNAL and still didn't work, > > yes I am looking into the debug command that will show me the gatekeeper call > flow. > I have been a long time never worked with that. > > Thanks for your ideas, > > I will keep you and the forum posted if I got any updates, > > Thanks, > Hesham > > > On 23 June 2013 01:40, Somphol Boonjing wrote: > Hi Hesham, > > I have a few ideas. I want to remove a few things out of the equation, > first try to set codec for all inter-region to G711. Second, if you are > using Local Route Group (LRG), replace it with a more straightforward > settings -- i.e. point the RL directly to HQ gateway in your case for > relevant route pattern. We can deal with them later on once we understand > this case to the bone. > > There are two call legs. The first call leg is from SC PH1 to reach x3001 > via a H323 Trunk on CUCM -- the Trunk with gatekeeper control. The call > should be directed to the gatekeeper who in turn should be routing it to the > H323 Trunk on CUCM. The H323 Trunk should have significant digits set to 4 > and a CSS that can reach x3001. > > Upon hitting x3001, CUCM will discover that the number is forwarded to > 9723033001. Assuming that you have set the CSS for CFUR on x3001 correctly, > that will match a Router Pattern that route the call toward HQ Gateway. > This is a second call leg.(If you use the LRG, at this point, the LRG for > the incoming H323 Trunk will cause the call to route to the wrong RG.) > > Once the second call leg is established, then CUCM will tell the two parities > to open the RTP channel directly to each other (i.e. between the CME and the > HQ Gateway.) (Well, sort of, if you have MTP required check on the H323 > Trunk, then an MTP will be involved.) > > You problem could be on either one of this. While I believe that since you > can make a call from HQ PH1 to x3001 successfully, the problem may not be in > the 2nd leg, I don't entirely want to rule out the CSS, the Significant > digits as well as the fact that HQ PH1 and the incoming H323 Trunk will be > more than likely belong to a different Device Pool & Region. > > I think "debug gatekeeper main 10" on the gatekeeper would help. > > On the H323 CUCM Trunk, RTMT Real Time monitoring with "Detailed Debug" turn > on would help you see whether the H323 Trunk has the right CSS to reach x3001. > > Hope this gives you some idea to work on this case. > > Regards, > --Somphol. > > > > > > On Sun, Jun 23, 2013 at 5:27 PM, Somphol Boonjing wrote: > Hi Hesham, > > Thanks for the detail explanation and well thanks for sharing the case. I > find it very intriguing. > > I'm working on some idea, but for now, I just want to forward your reply to > the group, in case anyone else can help too. > > > --Somphol > > > On Sun, Jun 23, 2013 at 4:44 PM, Hesham Abdelkereem > wrote: > Hi Somphol, > > I have to give you details as much as I can for better assistance not to > tackle some of the information. > Ok let me tell you the call flow > In my s
Re: [OSL | CCIE_Voice] B-ACD
Remove all of the param under the service did the trick, Say you have this in your running config application service app-b-acd param number-of-hunt-grps 2 param aa-hunt1 param aa-hunt2 1222 param queue-len 15 param queue-manager-debugs 1 ! Then, application service app-b-acd no param number-of-hunt-grps 2 no param aa-hunt1 no param aa-hunt2 1222 no param queue-len 15 no param queue-manager-debugs 1 Once there is no param set for the service, it will be removed from the running-config. --- Detail trace below: --- Branch2#show run | begin application application service app-b-acd param queue-len 15 param aa-hunt1 param queue-manager-debugs 1 param aa-hunt2 1222 param number-of-hunt-grps 2 ! ! Branch2(config)#application Branch2(config-app)# service app-b-acd Branch2(config-app-param)#no param queue-len 15 Warning: parameter queue-len has not been registered under app-b-acd namespace Branch2(config-app-param)#no param aa-hunt1 Warning: parameter aa-hunt1 has not been registered under app-b-acd namespace Branch2(config-app-param)# Branch2(config-app-param)#do show run | begin application application service app-b-acd param queue-manager-debugs 1 param aa-hunt2 1222 param number-of-hunt-grps 2 ! ! Branch2(config-app-param)#no param queue-manager-debugs 1 Warning: parameter queue-manager-debugs has not been registered under app-b-acd namespace Branch2(config-app-param)#no param aa-hunt2 1222 Warning: parameter aa-hunt2 has not been registered under app-b-acd namespace Branch2(config-app-param)#no param number-of-hunt-grps 2 Warning: parameter number-of-hunt-grps has not been registered under app-b-acd namespace Branch2(config-app-param)#do show run | begin application associate application SCCP ! dspfarm profile 5 conference codec g711ulaw codec g711alaw codec g729ar8 codec g729abr8 On Sun, Jun 23, 2013 at 12:20 AM, Bill Lake wrote: > Try doing all command not just these > > Sent from my iPhone > > On Jun 22, 2013, at 6:51 AM, CISCO CCIE VOICE > wrote: > > Thanks Bill for your reply, > > I have done no service app-b-acd and no service app-b-acd-aa but showing > all those commands in Running configuration > > thanks > > > > On Sat, Jun 22, 2013 at 1:48 PM, Bill Lake wrote: > >> If it is showing up in the running configuration, then you most likely >> see something like below, the best way to remove this is to no the commands >> >> Or to have done a Archive or copy of the config before you apply it. >> then restore that config as the startup and reboot. >> >> application >> >> * service app-b-acd * >> >> param number-of-hunt-grps 2 >> >> param aa-hunt2 >> >> param aa-hunt3 1222 >> >> param queue-len 15 >> >> param queue-manager-debugs 1 >> >> ! >> >> * service app-b-acd-aa * >> >> paramspace english index 1 >> >> paramspace english language en >> >> paramspace english location flash: >> >> param service-name app-b-acd >> >> param handoff-string app-b-acd-aa >> >> param aa-pilot 8005550123 >> >> param welcome-prompt _bacd_welcome.au >> >> param number-of-hunt-grps 2 >> >> param dial-by-extension-option 1 >> >> param second-greeting-time 60 >> >> param call-retry-timer 15 >> >> param max-time-call-retry 700 >> >> param max-time-vm-retry 2 >> >> param voice-mail 5003 >> >> ! >> >> dial-peer voice 222 voip >> >> service app-b-acd-aa >> >> destination-pattern 8005550123 >> >> session target ipv4:192.168.1.1 >> >> incoming called-number 8005550123 >> >> dtmf-relay h245-alphanumeric >> >> codec g711ulaw >> >> no vad >> >> >> >> On Sat, Jun 22, 2013 at 2:25 AM, Somphol Boonjing wrote: >> >>> That one is the embedded one so you actually can not remove it. >>> However, you can simply ignore it and use one that is external script. >>> >>> So, if you have the external BACD script, you can use it instead of the >>> embedded one. >>> >>> Branch2#show flash | inc bacd >>> 107 30421bacd/app-b-acd-3.0.0.2.tcl >>> 108 55599bacd/app-b-acd-aa-3.0.0.2.tcl >>> >>> application >>> service *funnyqueue flash:/bacd/*app-b-acd-3.0.0.2.tcl >>> <-- you can you whatever name you like, in this >>> case "funnyqueue" >>> <-- point the script to the script with correct >>> path >>>. (detail remove for brevity)... >>> >>> ! >>> >>> service* funnyaa flash:/bacd/app-b-acd-aa-3.0.0.2.tcl * >>> <-- you can you whatever name you like, in this >>> case "funnyaa" >>> <-- point the script to the script with correct >>> path >>>. (detail remove for brevity). >>>param service-name *funnyqueue* <-- refer to your queue application >>> name >>>param handoff-string *funnyaa* >>>. (detail remove for brevity). >>> >>> ! >>> >>> dial-peer voice 222 voip >>> service *funnyaa* <-- refer to your AA application name. >>>. (detail remove
Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
Hi Hesham, I have a few ideas. I want to remove a few things out of the equation, first try to set codec for all inter-region to G711. Second, if you are using Local Route Group (LRG), replace it with a more straightforward settings -- i.e. point the RL directly to HQ gateway in your case for relevant route pattern. We can deal with them later on once we understand this case to the bone. There are two call legs. The first call leg is from SC PH1 to reach x3001 via a H323 Trunk on CUCM -- the Trunk with gatekeeper control. The call should be directed to the gatekeeper who in turn should be routing it to the H323 Trunk on CUCM. The H323 Trunk should have significant digits set to 4 and a CSS that can reach x3001. Upon hitting x3001, CUCM will discover that the number is forwarded to 9723033001. Assuming that you have set the CSS for CFUR on x3001 correctly, that will match a Router Pattern that route the call toward HQ Gateway.This is a second call leg.(If you use the LRG, at this point, the LRG for the incoming H323 Trunk will cause the call to route to the wrong RG.) Once the second call leg is established, then CUCM will tell the two parities to open the RTP channel directly to each other (i.e. between the CME and the HQ Gateway.) (Well, sort of, if you have MTP required check on the H323 Trunk, then an MTP will be involved.) You problem could be on either one of this. While I believe that since you can make a call from HQ PH1 to x3001 successfully, the problem may not be in the 2nd leg, I don't entirely want to rule out the CSS, the Significant digits as well as the fact that HQ PH1 and the incoming H323 Trunk will be more than likely belong to a different Device Pool & Region. I think "debug gatekeeper main 10" on the gatekeeper would help. On the H323 CUCM Trunk, RTMT Real Time monitoring with "Detailed Debug" turn on would help you see whether the H323 Trunk has the right CSS to reach x3001. Hope this gives you some idea to work on this case. Regards, --Somphol. On Sun, Jun 23, 2013 at 5:27 PM, Somphol Boonjing wrote: > Hi Hesham, > > Thanks for the detail explanation and well thanks for sharing the case. > I find it very intriguing. > > I'm working on some idea, but for now, I just want to forward your reply > to the group, in case anyone else can help too. > > > --Somphol > > > On Sun, Jun 23, 2013 at 4:44 PM, Hesham Abdelkereem < > heshamcentr...@gmail.com> wrote: > >> Hi Somphol, >> >> I have to give you details as much as I can for better assistance not to >> tackle some of the information. >> Ok let me tell you the call flow >> In my scenario >> HQ and SB are registered to CUCM and SC is a CME (SC is connected with HQ >> & SB via Gatekeeper) >> I want to make sure that in case of SB WAN Failure HQ/SC phones are able >> to call Siteb phone using 4 digits in the event of wan failue.When you call >> from HQ phone calls should be routed through HQ gateway. When you call from >> SC Phones calls should be routed through the GK and then HQ Gateway. >> >> In normal operation the call flow is >> HQ dials 4xxx ---> Gatekeeeper ---> SC CME >> SB dials 4xxx ---> Gatekeeper ---> SC CME >> >> now when you configure Call Forward Unregister internal >> >> HQ dials 3XXX --> SB phone is no longer registered to CUCM and is >> configured for internal and external if Unregistered to be forwarded to >> 9723033001 > Number is dialed on HQ Gateway by CFUR ---> Call reaches >> SB via HQ PSTN Gateway successfully >> >> the Requirement now >> >> SC CME dials 3XXX--->Call Router via Gatekeeper--> SB phone is no longer >> registered to CUCM and is configured for internal and external if >> Unregistered to be forwarded to 9723033001---> Number is dialed on HQ >> Gateway by CFUR ---> Call reaches SB via HQ PSTN Gateway successfully. >> >> Now the current situation >> >> when SC CME dials 3XXX when the SB is under WAN Failure it goes no where >> after the Gatekeeper >> but when I switch back the SB Phones to be registered to CUCM rather than >> CALL MANAGER FALLBACK >> the call go through via Gatekeeper >> >> >> Many Thanks, >> Hesham >> >> >> On 22 June 2013 23:26, Somphol Boonjing wrote: >> >>> Hi Hesham, >>> >>> > knowing that Gatekeeper is working with SiteB under normal operation >>> but doesn't work with CFUR >>> >>> Could you please clarify the problem you are facing? What do you mean >>> when you say the gatekeeper is not working with CFUR? >>> >>> > Any Ideas, >>> >>> I think we will need to simplify the scenario to the level that we can >>> understand the expected call flow correctly, then from there we can isolate >>> problematic area further. >>> >>> 'debug isdn q931' on HQ GW and SiteB GW might also give us some more >>> idea. >>> >>> Regards, >>> >>> >>> --Somphol >>> >>> >>> On Sun, Jun 23, 2013 at 12:45 PM, Hesham Abdelkereem < >>> heshamcentr...@gmail.com> wrote: >>> Dear Experts, SiteC is CME and connected with HQ and SB via Gatekeeper
Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
Hi Hesham, Thanks for the detail explanation and well thanks for sharing the case. I find it very intriguing. I'm working on some idea, but for now, I just want to forward your reply to the group, in case anyone else can help too. --Somphol On Sun, Jun 23, 2013 at 4:44 PM, Hesham Abdelkereem < heshamcentr...@gmail.com> wrote: > Hi Somphol, > > I have to give you details as much as I can for better assistance not to > tackle some of the information. > Ok let me tell you the call flow > In my scenario > HQ and SB are registered to CUCM and SC is a CME (SC is connected with HQ > & SB via Gatekeeper) > I want to make sure that in case of SB WAN Failure HQ/SC phones are able > to call Siteb phone using 4 digits in the event of wan failue.When you call > from HQ phone calls should be routed through HQ gateway. When you call from > SC Phones calls should be routed through the GK and then HQ Gateway. > > In normal operation the call flow is > HQ dials 4xxx ---> Gatekeeeper ---> SC CME > SB dials 4xxx ---> Gatekeeper ---> SC CME > > now when you configure Call Forward Unregister internal > > HQ dials 3XXX --> SB phone is no longer registered to CUCM and is > configured for internal and external if Unregistered to be forwarded to > 9723033001 > Number is dialed on HQ Gateway by CFUR ---> Call reaches > SB via HQ PSTN Gateway successfully > > the Requirement now > > SC CME dials 3XXX--->Call Router via Gatekeeper--> SB phone is no longer > registered to CUCM and is configured for internal and external if > Unregistered to be forwarded to 9723033001---> Number is dialed on HQ > Gateway by CFUR ---> Call reaches SB via HQ PSTN Gateway successfully. > > Now the current situation > > when SC CME dials 3XXX when the SB is under WAN Failure it goes no where > after the Gatekeeper > but when I switch back the SB Phones to be registered to CUCM rather than > CALL MANAGER FALLBACK > the call go through via Gatekeeper > > > Many Thanks, > Hesham > > > On 22 June 2013 23:26, Somphol Boonjing wrote: > >> Hi Hesham, >> >> > knowing that Gatekeeper is working with SiteB under normal operation >> but doesn't work with CFUR >> >> Could you please clarify the problem you are facing? What do you mean >> when you say the gatekeeper is not working with CFUR? >> >> > Any Ideas, >> >> I think we will need to simplify the scenario to the level that we can >> understand the expected call flow correctly, then from there we can isolate >> problematic area further. >> >> 'debug isdn q931' on HQ GW and SiteB GW might also give us some more idea. >> >> Regards, >> >> >> --Somphol >> >> >> On Sun, Jun 23, 2013 at 12:45 PM, Hesham Abdelkereem < >> heshamcentr...@gmail.com> wrote: >> >>> Dear Experts, >>> >>> >>> SiteC is CME and connected with HQ and SB via Gatekeeper >>> Gatekeeper is working excellent with HQ and SB >>> I am configuring Call Forward Unregister for SiteB. >>> SiteB has Call-Manager-Fallback mode working excellent >>> >>> Now, I have configured Call Forward Unregister >>> in the service parameter I changed maximum hops to DN unregister is 1 >>> >>> I have Created a Partitions and CSS for CFUR >>> I forward SiteB1 and SiteB2 telephones in unregisted internal and >>> external to be 9723033001 with forward css CFUR-CSS >>> >>> I created Route List to point to HQ Router >>> and create route pattern for CFUR >>> >>> Now gatekeeper is reaching both HQ and SiteB in normal operaiton >>> when I put SiteB under call-manager-fallback mode >>> when I dial from HQ 3001 the CFUR works and shows the E164 number >>> when I dial from SiteC 3001 via gatekeeper it shows unknown number >>> >>> knowing that Gatekeeper is working with SiteB under normal operation but >>> doesn't work with CFUR >>> >>> Any Ideas, >>> >>> Thanks, >>> Hesham >>> >>> ___ >>> 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 is unable to reach SiteB under Call Forward UnRegister
Dear Hesham, As far as I understand from your email, SiteB is now in SRST mode, which means that SiteB WAN connection is down. In this case, SiteC won't be able to reach SiteB phones over the WAN through GK but you will have to configure a lower preference dial-peer to reach it through PSTN in case the GK rejects or can't reach SiteB phones. Thanks,Ramy Date: Sat, 22 Jun 2013 19:45:41 -0700 From: heshamcentr...@gmail.com To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister Dear Experts, SiteC is CME and connected with HQ and SB via GatekeeperGatekeeper is working excellent with HQ and SB I am configuring Call Forward Unregister for SiteB. SiteB has Call-Manager-Fallback mode working excellent Now, I have configured Call Forward Unregisterin the service parameter I changed maximum hops to DN unregister is 1 I have Created a Partitions and CSS for CFURI forward SiteB1 and SiteB2 telephones in unregisted internal and external to be 9723033001 with forward css CFUR-CSS I created Route List to point to HQ Router and create route pattern for CFUR Now gatekeeper is reaching both HQ and SiteB in normal operaitonwhen I put SiteB under call-manager-fallback modewhen I dial from HQ 3001 the CFUR works and shows the E164 number when I dial from SiteC 3001 via gatekeeper it shows unknown number knowing that Gatekeeper is working with SiteB under normal operation but doesn't work with CFUR Any Ideas, Thanks,Hesham ___ 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
