[cisco-voip] GK w/ MGCP/SRST Gateways - Toll Bypass Routing

[Mike Brooks]

Hi Jason,

I new that could come up.

If I remember correctly, one of the main reasons for this method is because
all calls forwarded to voicemail could never be routed using AAR. This is
because the telcos dont support RDNIS, and therefore forward calls would not
be routed to the proper mailbox in Unity when going over the PSTN.  Other
non VM calls can traverse the PSTN rather than the WAN without issues
because they are not dependent on RDNIS.

Correct me if I am wrong, but I believe the locations parameter is on the
voicemail ports. Which means in order for AAR "NOT" to be invoked on calls
forwarded to VM then each office would need to have dedicated VM ports
rather than using the same pool of ports for all offices.

The gatekeeper provided a solution to this problem by not routing calls to
Unity through the gatekeeper, therefore not rerouting the call based on
bandwidth limitations.

I believe there was some other reasons for the madness and I know its a
little messy but it actually works pretty good.  All tollbypass calls
(besides VM ;-) ) is controlled on the gatekeeper for all SRST offices and
non SRST cluster offices.

I am pretty sure this problem would exist regardless of if we had used
locations/AAR rather than the gatekeeper because CFUR is not supported on CM
5.X.

I think its actually more likely to have some sort of dynamic method to stop
toll bypass routing when an mgcp gateway goes into SRST mode using the
gatekeeper rather than on CM.

I am sure some sort of script can do it, but I was hoping to use something a
little less custom.

Any suggestions ?

Regards,

Mike Brooks
CCIE# 16027 (R&S)


On Thu, Feb 26, 2009 at 6:40 AM, Jason Burns <burns.jason at gmail.com> wrote:

> Why do the calls between offices have to go through a GK? Sounds painful to
> me.
>
> If it's a call between two IP Phones, both registered to the same
> CallManager Cluster, I'd leave the GK out of the picture completely to stop
> my brain from exploding.
>
> Is there something that precludes you from using CallManager Locations and
> AAR?
>
>
>   On Wed, Feb 25, 2009 at 2:37 PM, Mike Brooks <2xccie2b at gmail.com> wrote:
>
>>   Hi everyone,
>>
>> I have a tough question for you guys.
>>
>> *Scenario:*
>> Say you have a network in which you have multiple SRST offices that are
>> centrally managed by a a single cluster running CallManager 5.x.  Calls
>> within each office are obviously routed by the callmanager but between the
>> SRST offices the calls are routed by a centrally located gatekeeper.  Calls
>> to and from "other" clusters, "non-srst", are routed by the gatekeeper to
>> and from these SRST offices as well.
>>
>> The issue is that the SRST offices are actually MGCP gateways not H323.
>> Therefore, instead of having connections between the SRST gateways and the
>> GK you have trunks between the GK and the SRST office.  Each trunk
>> represents an SRST office. The gatekeeper contains a seperate zone for each
>> SRST office.  Calls destined to other SRST offices are routed to the
>> gatekeeper.  The gatekeeper performs call routing based on the zone prefixes
>> and checks if enough bandwidth exists between SRST offices (trunks) to make
>> the call and routes it back to the SRST cluster identifying the appropriate
>> trunk.  If not enough bandwidth is not available then the GK rejects the
>> call and the call is routed out to the PSTN.
>>
>> *Problem:*
>> The problem is when an MGCP gateway goes in SRST mode the gatekeeper does
>> not know the office is not reachable.  The gatekeeper just knows the trunk
>> is still accessible which does not represent the status of the actually
>> gateway/office.  Therefore calls would be routed directly to Voicemail.
>> CFUR is not available on CM 5.x.  Therefore all offices (including
>> operations ;-) ) would not be able to call phones in that office at all when
>> that site is in SRST mode.
>>
>> It would require manual intervention of someone going into the gatekeeper
>> and lowering the bandwidth statement for the zone that represents the SRST
>> office.  Then the gatekeeper would reject the call and the call would be
>> routed across the PSTN and into the office that is in SRST mode.
>>
>> So my questions is ....  does anyone know of a dynamic way to have the
>> gatekeeper poll the MGCP gateway and if that MGCP gateway is not reachable
>> then it .... rejects the call  ... rather than forwarding to the gateways
>> associated trunk ... and directly to voicemail.   For example, if the MGCP
>> gateway is not reachable it lowers the bandwidth statement for the
>> associated trunk to 1.
>>
>> Perhaps something to do with IPSLA....
>>
>> I know its a complex situation, just wondering if anyone had "any"
>> suggestions.
>>
>> Your input would be greatly appreciated.
>>
>> Regards,
>>
>> Mike Brooks
>> CCIE# 16027 (R&S)
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090226/ac6cf7e5/attachment.html>