I noticed a typo in that last email (sorry, I clicked "send" too soon) - in the 3 options for H323 digit manipulation, I said num-exp will be between the inbound voip dial peer and outbound *VOIP *dial peer...*the outbound dial peer is POTS* in this case, not voip. (using two voip dial-peers on both inbound and outbound is CUBE, which is not relevant to AAR configuration).
-Justin On Fri, Feb 1, 2013 at 11:46 PM, Justin Carney <justin.s.car...@gmail.com>wrote: > Yes, AAR is triggered on CAC reporting out of bandwidth. (Side note - the > phone will display "Network Congestion. Rerouting" and this is a service > parameter that can be customized, in case that is part of the question > requirement.) You are also correct that both phones must be registered to > the same CUCM cluster. I don't understand if your last sentence is a > question - "for some reason that call fails to call by extension" - if > there is a CSS/PT issue where phone A can't see the DN of phone B, AAR will > not kick in. Under normal conditions phone A must be able to call phone B, > then when there is no more bandwidth (per CAC) AAR will reroute via PSTN. > If the phone B were in SRST mode and the WAN was down, not congested, this > would instead use CFUR to reroute. > > I'll answer question 2 first. A common way to achieve AAR is to use a > separate CSS/PT just for AAR, along with an AAR Group assigned to both > lines (you can assign AAR group to phones for other reasons, but you *must* > put the AAR group on the line/DN). When AAR is triggered (CAC), the called > phone B's external number mask will be the new DNIS which should be in > E.164 format already, and the calling phone A's AAR-CSS will be used to > lookup a route for that DNIS. Simply put a \+.! route pattern in your > AAR-PT that routes to the LRG, and the AAR-CSS should contain this AAR-PT. > This gets the call to the gateway. If the gateway is MGCP, you may need > to manipulate the plan/type to match what the PSTN expects (You may > also/instead need to have a \+1.! pattern in AAR-PT in the event your MGCP > router's PRI expect a 10 digit DNIS.) For H323 don't do any digit > manipulation here, used the gateway to perform all manipulations. > > Question 1, dial peers needed. If using the strategy above, you might not > need any new dial peers. For the MGCP sites there are no dial peers on the > router so you are done after CUCM routes the call to the gateway in the > proper format. > > For the H323 sites that need to route the AAR call, the DNIS will be the > E.164 number when the call gets to the inbound voip dial peer. If you have > an existing outbound pots dial peer that will match this E164 number there > is nothing extra to do, your AAR call should be working. (make sure you > have the appropriate number of digits and type/plan sent to the PSTN for > both ANI and DNIS). If your existing dial peers do not match, you have a > few options: > > 1. you could *use a translation-profile on the inbound voip dial peer *to > manipulate the DNIS into something that matches an existing outbound POTS > dial peer > 1. for example if your DNIS is +1 408 555 1234, you would change > the +1 to 91 and you would match the existing long distance outbound > dial > peer > 2. you could *add a new outbound dial peer that will match this > DNIS*(optionally putting a translation-profile on this dial peer if you need a > specific plan/type) > 1. for example if your DNIS is +1 408 555 1234, you can copy your > existing long distance dial peer (9+11 digits) and just remove the 9 > (leaving 11 digits) > 3. A third option (I would recommend you do NOT use this option) would > be to use number expansion to manipulate the DNIS between the inbound voip > dial peer match and the outbound voip dial peer match - the reason I don't > recommend this is because number expansion ALWAYS takes place between the > inbound and outbound dial peers even if you don't want it to. This means > if you're not careful it could break something else that was already > working correctly. > > For question 3, TEHO - if you use the method above, your TEHO patterns > will be not be visible to the AAR-CSS and there will be no conflict between > TEHO patterns and the new AAR pattern. If you didn't have an isolated AAR > CCS and PT, then it would be problematic if your AAR number in E164 format > was matching a TEHO pattern that would send the call over the congested WAN > link that trigger AAR in the first place - this obviously would not work. > > Hope this helps...if it doesn't I'm probably too tired to make sense and > I'll edit my response tomorrow :-) > > -Justin > > On Fri, Feb 1, 2013 at 10:04 PM, ie ravindra <ieravin...@gmail.com> wrote: > >> Hi Mates, >> >> As per my understanding AAR is triggering when if CAC enabled and if for >> some reason that call cannot be completed. Therefore we need route that >> call to the PSTN. The mandatory requirement is the both extensions must >> register to the same call manager clusted. If Caller A calling to User B. >> for Some reason that call fails to call by extension. AAR group grabs long >> number(AAR Number) from User B's Settings. and Dialls out. >> >> I have following Questions in the above. >> >> 1. when AAR is enabled if we have 3 sites, do we need to have 3 dialpeers >> to dialout the call. >> >> 2 What is the remomend way to make a dialplan for Multisite deployment. >> 3. As per my knowledge TEHO patterns should not be conflicted. >> >> If I am wrong on above statements please connect me. >> >> Thanks for Helping US, >> Ravi. :) >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com >> > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
