[apologies in advance for out-loud thought process]<br><br>Well, here's a potentially simple solution.<br><br>On the Route List with the trunk, add a second Route Group to the PSTN. If the call gets an ARJ (or no response because the WAN link is down), prepend the 91 and area code and send it to a PRI.
<br><br>Downside here is that they probably have ONE ICT to their gatekeeper and probably 90+ different area codes and office codes on the other side.<br><br>So, do all of this on the gatekeeper... <br><br>Have the gatekeeper connect to a few
H.323 gateways and have the gatekeeper reroute the call to one of them when the ICT is down (but this only fixes you one way...)<br><br>Third option.<br><br>Create 90+ ICTs. One for each site, but all going to the gatekeeper (this should completely exceed your GKs capacity...), with the same number of Route-Lists... each, with the second PRI gateway, with the correct dial-plan transformation to get the call to the correct site.
<br><br>This way, if the link from that cluster to the GK is down, calls will still proceed as normal to the user.<br><br>But I wouldn't want to configure it.<br><br><br><br>Jonathan<br><br><div><span class="gmail_quote">
On 12/12/06, <b class="gmail_sendername">Barbara Fenner</b> <<a href="mailto:barbara.fenner@gmail.com">barbara.fenner@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Does anyone know how this will affect existing TEHO deployments that utilize the function for 4.x when upgarding to 5.x and on? Using an additional RG doesn't mean alot to you or I but a user with 90+ ICT links with AAR routing backup will probably loose a night or two working that out...
<br><br>
<div><div><span class="e" id="q_10f784419e1e4b8a_1"><span class="gmail_quote">On 12/12/06, <b class="gmail_sendername">Jonathan Charles</b> <<a href="mailto:jonvoip@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
jonvoip@gmail.com</a>> wrote:</span>
</span></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><div><span class="e" id="q_10f784419e1e4b8a_3">An update on this, according to the SRND for
CCM4.2, page 9-14:<br><br>"AAR is invoked only when the locations-based call admission control denies the call due to a lack of network bandwidth. AAR is not invoked when the IP WAN is unavailable or other connectivity issues cause the called device to become unregistered with Cisco Unified CallManager. In such cases, the calls are redirected to the target specified in the Call Forward No Answer field of the called device."
<br><br><br><br>Jonathan<br><br>
<div><span class="gmail_quote">On 11/21/06, <b class="gmail_sendername">Howard, Chad</b> <<a href="mailto:Chad.Howard@ecolab.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Chad.Howard@ecolab.com
</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div dir="ltr" align="left"><span><font face="Arial" size="2">I was able to set this up in a lab finally. The setup is two separate CCM 5.04 clusters with gatekeeper-controlled intercluster trunks. <span name="st">AAR</span>
within a cluster works as expected.</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Unless I messed something up, an ARJ from gatekeeper does not invoke <span name="st">AAR</span>. You have to put a route group for a gateway into the route list so you have PSTN backup in this scenario.
</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">I tried gatekeeper "bandwidth interzone..." CAC as well as just locations-based CAC on the ICT and remote phone. All gave me fast-busy if there wasn't enough bandwidth for a given location.
</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Hope this helps.</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">cisco-voip-bounces@puck.nether.net</a> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Howard, Chad<br><b>Sent:</b> Friday, November 17, 2006 5:22 PM<br><b>To:</b> Wes Sisk; Jonathan Charles</font>
<div><span><font face="Tahoma" size="2"><br><b>Cc:</b> ciscovoip<br><b>Subject:</b> Re: [cisco-voip] AAR question...<br></font></span></div><br> </div>
<div><span>
<div></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Another question along the same lines...</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">If using gatekeeper for intercluster calls (dial resolution only, not CAC on the gatekeeper itself), does CM distinguish between between a reject due to "the DN does not exist on the remote cluster" versus "insufficient location bandwith" on the remote cluster ?
</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" size="2">Or does an 'insufficient bandwidth' rejection have to come from the gatekeeper's locally configured CAC in order to invoke AAR? (all rejects from remote clusters look the same regardless of underlying reason)
</font></span></div>
<div> </div>
<div><span></span><font face="Arial"><font size="2">T<span>hanks.</span></font></font><br> </div>
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">cisco-voip-bounces@puck.nether.net</a> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Wes Sisk<br><b>Sent:</b> Friday, November 17, 2006 4:34 PM<br><b>To:</b> Jonathan Charles<br><b>Cc:</b> ciscovoip<br><b>Subject:</b> Re: [cisco-voip] AAR question...
<br></font><br> </div>
<div></div>AAR works with ARJ as well. CM will reroute using AAR CSS.<br><br>/Wes<br><br>Jonathan Charles wrote:
<blockquote cite="http://mid5d093f9a0611170829q4fdf0ad8v644a4599b43d1f00@mail.gmail.com" type="cite">Found this quote in the SRND for 4.1:<br><br>"<span> Automated alternate routing (AAR) provides a mechanism to reroute calls through the PSTN or other network by using an alternate number when Cisco CallManager blocks a call due to insufficient location bandwidth."
<br><br>My question is, what happens if a Gatekeeper rejects the call, does this count as 'insufficient location bandwidth' or does AAR only work if locations-based bandwidth is exceeded? <br><br><br><br><br>Jonathan<br>
</span>
<pre><hr size="4" width="90%">
_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">cisco-voip@puck.nether.net</a>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre></blockquote><pre>CONFIDENTIALITY NOTICE: <br>This e-mail communication and any attachments may contain proprietary and privileged information for the use of the designated recipients named above. <br>Any unauthorized review, use, disclosure or distribution is prohibited.
<br><br>If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.<br><br></pre></span></div></div>
<div><span><pre>CONFIDENTIALITY NOTICE: <br>This e-mail communication and any attachments may contain proprietary and privileged information for the use of the designated recipients named above. <br>Any unauthorized review, use, disclosure or distribution is prohibited.
<br><br>If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.<br><br></pre></span></div></blockquote></div><br><br></span></div>_______________________________________________
<span class="q"><br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://puck.nether.net/mailman/listinfo/cisco-voip</a><br><br><br></span></blockquote></div><br>
</blockquote></div><br>