[cisco-voip] AAR question...

[Jonathan Charles]

[apologies in advance for out-loud thought process]

Well, here's a potentially simple solution.

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.

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.

So, do all of this on the gatekeeper...

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...)

Third option.

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.

This way, if the link from that cluster to the GK is down, calls will still
proceed as normal to the user.

But I wouldn't want to configure it.



Jonathan

On 12/12/06, Barbara Fenner <barbara.fenner at gmail.com> wrote:
>
> 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...
>
> On 12/12/06, Jonathan Charles <jonvoip at gmail.com> wrote:
>
> > An update on this, according to the SRND for CCM4.2, page 9-14:
> >
> > "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."
> >
> >
> >
> > Jonathan
> >
> > On 11/21/06, Howard, Chad <Chad.Howard at ecolab.com > wrote:
> > >
> > >  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.  AAR within a cluster works as expected.
> > >
> > > Unless I messed something up, an ARJ from gatekeeper does not invoke
> > > AAR.  You have to put a route group for a gateway into the route list
> > > so you have PSTN backup in this scenario.
> > >
> > > 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.
> > >
> > > Hope this helps.
> > >
> > >
> > >  ------------------------------
> > > *From:* cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net]
> > > *On Behalf Of *Howard, Chad
> > > *Sent:* Friday, November 17, 2006 5:22 PM
> > > *To:* Wes Sisk; Jonathan Charles
> > > *Cc:* ciscovoip
> > > *Subject:* Re: [cisco-voip] AAR question...
> > >
> > >
> > >  Another question along the same lines...
> > >
> > > 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 ?
> > >
> > > 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)
> > >
> > > Thanks.
> > >
> > >  ------------------------------
> > > *From:* cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net]
> > > *On Behalf Of *Wes Sisk
> > > *Sent:* Friday, November 17, 2006 4:34 PM
> > > *To:* Jonathan Charles
> > > *Cc:* ciscovoip
> > > *Subject:* Re: [cisco-voip] AAR question...
> > >
> > >
> > > AAR works with ARJ as well.  CM will reroute using AAR CSS.
> > >
> > > /Wes
> > >
> > > Jonathan Charles wrote:
> > >
> > > Found this quote in the SRND for 4.1:
> > >
> > > " 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."
> > >
> > > 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?
> > >
> > >
> > >
> > >
> > > Jonathan
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > cisco-voip mailing list
> > > cisco-voip at puck.nether.net
> > >
> > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > >
> > > CONFIDENTIALITY NOTICE:
> > > This e-mail communication and any attachments may contain proprietary and privileged information for the use of the designated recipients named above.
> > > Any unauthorized review, use, disclosure or distribution is prohibited.
> > >
> > > If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> > >
> > > CONFIDENTIALITY NOTICE:
> > > This e-mail communication and any attachments may contain proprietary and privileged information for the use of the designated recipients named above.
> > > Any unauthorized review, use, disclosure or distribution is prohibited.
> > >
> > > If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> > >
> > >
> >
> > _______________________________________________
> > 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/20061212/adcb0b4a/attachment-0001.html