Why do the calls between offices have to go through a GK? Sounds painful to me.<br><br>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.<br>
<br>Is there something that precludes you from using CallManager Locations and AAR?<br><br><br><div class="gmail_quote">On Wed, Feb 25, 2009 at 2:37 PM, Mike Brooks <span dir="ltr"><<a href="mailto:2xccie2b@gmail.com">2xccie2b@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><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><font color="#888888">
<div>Mike Brooks</div>
<div>CCIE# 16027 (R&S)</div>
<div> </div>
<div> </div>
</font><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br>