Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
Guys I got the fix, The problem was a typo error due to my fast copy and paste in SB router i type gateway command by default and that resulted the following R1#sh gatekee end GATEKEEPER ENDPOINT REGISTRATION CallSignalAddr Port RASSignalAddr Port Zone Name TypeFlags --- - --- - - - 142.100.64.11 41758 142.100.64.11 32793 GKVOIP-GW H323-ID: GK-Trunk_1 Voice Capacity Max.= Avail.= Current.= 0 142.100.64.12 37277 142.100.64.12 32790 GKVOIP-GW H323-ID: GK-Trunk_2 Voice Capacity Max.= Avail.= Current.= 0 142.102.65.254 1720 142.102.65.254 57138 GKH323-GW E164-ID: 3002 E164-ID: 3001 Voice Capacity Max.= Avail.= Current.= 0 142.102.66.254 1720 142.102.66.254 51323 GKH323-GW H323-ID: CUCME Voice Capacity Max.= Avail.= Current.= 0 Total number of active registrations = 4 R1# so it was invalid when i deleted the gateway from SiteB gateway it fixed the problem Thank you very much guys Special Thanks to Bill , Ramy and Somphol Hesham On 23 June 2013 04:00, Somphol Boonjing wrote: > 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
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] 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] 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
Re: [OSL | CCIE_Voice] Gatekeeper is unable to reach SiteB under Call Forward UnRegister
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
[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 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
