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 Type Flags
--------------- ----- --------------- ----- --------- ---- -----
142.100.64.11 41758 142.100.64.11 32793 GK VOIP-GW
H323-ID: GK-Trunk_1
Voice Capacity Max.= Avail.= Current.= 0
142.100.64.12 37277 142.100.64.12 32790 GK VOIP-GW
H323-ID: GK-Trunk_2
Voice Capacity Max.= Avail.= Current.= 0
142.102.65.254 1720 142.102.65.254 57138 GK H323-GW
E164-ID: 3002
E164-ID: 3001
Voice Capacity Max.= Avail.= Current.= 0
142.102.66.254 1720 142.102.66.254 51323 GK H323-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 <somp...@gmail.com> 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 <somp...@gmail.com>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 <somp...@gmail.com> 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 <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 <http://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
