I use this method to prevent having to do any additional dial peers in H323.

 

If only one site is using AAR

MCGP - strip as may digits as you need on the AAR Route Pattern to match the
called party requirements of the lab and use external mask to satisfy the
calling party requirements 

H323 - strip and prefix digits on the called number to match an existing
dialpeer on the gateway.  Do not do any calling number manipulations as that
is already taken care of by the dial peer

 

If both sites are using AAR

Attach calling called number transformations to the gateway to achieve
everything from above

 

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Justin Carney
Sent: Friday, February 01, 2013 11:56 PM
To: ie ravindra
Cc: CCIE Study
Subject: Re: [OSL | CCIE_Voice] [OSL | Automated Alternative Routing]

 

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 <[email protected]>
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
<tel:%2B1%20408%20555%201234> , 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
<tel:%2B1%20408%20555%201234> , 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 <[email protected]> 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

Reply via email to