<div>Hi Jason,</div>
<div> </div>
<div>I new that could come up.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>I am sure some sort of script can do it, but I was hoping to use something a little less custom.</div>
<div> </div>
<div>Any suggestions ? </div>
<div> </div>
<div>Regards,</div>
<div> </div>
<div>Mike Brooks</div>
<div>CCIE# 16027 (R&S)</div>
<div><br> </div>
<div class="gmail_quote">On Thu, Feb 26, 2009 at 6:40 AM, Jason Burns <span dir="ltr"><<a href="mailto:burns.jason@gmail.com" target="_blank">burns.jason@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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">
<div>
<div></div>
<div>On Wed, Feb 25, 2009 at 2:37 PM, Mike Brooks <span dir="ltr"><<a href="mailto:2xccie2b@gmail.com" target="_blank">2xccie2b@gmail.com</a>></span> wrote:<br></div></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<div>
<div></div>
<div>
<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></div></div>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">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></blockquote></div><br>