<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mike,<br>
<br>
Sounds like a network a bit ahead of its time.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
A little more googling....<br>
<br>
This looks promising:<br>
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_configuration_guide_chapter09186a0080557e81.html">http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_configuration_guide_chapter09186a0080557e81.html</a><br>
<br>
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.<br>
<br>
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:<br>
1. detect dial-peer shutdown<br>
2. reconfigure GK zone to impossibly low bw (like 0?)<br>
3. force reroute over PSTN.<br>
<br>
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.<br>
<br>
This is provided as is with no support or warranty. YMMV extremely.<br>
<br>
/Wes<br>
<br>
On Wednesday, February 25, 2009 2:37:30 PM, Mike Brooks
<a class="moz-txt-link-rfc2396E" href="mailto:2xccie2b@gmail.com"><2xccie2b@gmail.com></a> wrote:<br>
<blockquote
cite="mid:267fca630902251137p1297a941i89feb22c62c2a89a@mail.gmail.com"
type="cite">
<div>Hi everyone,</div>
<div> </div>
<div>I have a tough question for you guys. </div>
<div> </div>
<div><u>Scenario:</u></div>
<div>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. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div><u>Problem:</u></div>
<div>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. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>Perhaps something to do with IPSLA.... </div>
<div> </div>
<div>I know its a complex situation, just wondering if anyone
had "any" suggestions. </div>
<div> </div>
<div>Your input would be greatly appreciated.</div>
<div> </div>
<div>Regards,</div>
<div> </div>
<div>Mike Brooks</div>
<div>CCIE# 16027 (R&S)</div>
<div> </div>
<div> </div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<br>
</body>
</html>