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 <somp...@gmail.com> 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 <somp...@gmail.com>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 <somp...@gmail.com> 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
