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

Wes Sisk wsisk at cisco.com
Wed Feb 25 21:51:39 EST 2009

Hi Mike,

Sounds like a network a bit ahead of its time.

As for the GK, i have only seen one valid and working design that 
required both CM Locations and GK.  That was a very structured network 
with numerous 'hubs' per region.  CM locations maintained CAC for 
circuits within the region.  GK was used for CAC between regions.  This 
was a proper tiered model if you will.

Your call flow reminds me of some CVP call flows but those are 
introduced specifically to have CVP, GK, and VXML in the picture to 
select agents across multiple CM clusters.

Perhaps the best possible solution is "call forward unregister".  Are 
you sure you cannot upgrade?  CM6.x or even 7.x has many new features 
like greater stability.

Resource Availability Indicator (RAI) intregrates with GK to allow more 
effective load balancing over endpoints.  This is getting close to what 
you are looking for.

A little more googling....

This looks promising:

I have not used it before but I see a few promising descriptions of this 
"monitor probe icmp-ping" command that looks like it will shut a 
dial-peer with loss of connectivity possibly to an alternate address.

So that will get you notification that connectivity to a remote site has 
been lost.  I suspect you can combine that with a bit of creative EEM 
scripting on the router to:
1. detect dial-peer shutdown
2. reconfigure GK zone to impossibly low bw (like 0?)
3. force reroute over PSTN.

it is not a 'canned' solution.  However, if you were industrious enough 
to introduce gatekeeper into this design I suspect a bit of EEM 
scripting will be a welcome change from the daily routine.

This is provided as is with no support or warranty.  YMMV extremely.


On Wednesday, February 25, 2009 2:37:30 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/20090225/9c1f0ae0/attachment.html>

More information about the cisco-voip mailing list