Cart
Today I’m going to write about the AAR feature in Call Manager, and the changes in configuration introduced with CUCM 7.0.
Automated alternate routing is a way to re-route an call between two endpoints in the same cluster via an alternate route (most likely the PSTN) when the call admission control mechanism (Call Manager CAC or RSVP) determines there’s not enough bandwidth between two locations to route a call via VoIP.
Therefore, several things should happen for a call to be properly rerouted by this feature:
- Both phones involved in the call must be registered to CUCM
- Location’s Bandwidth is not enough to allow the call to go through between the two devices directly over the wan connection. Keep in mind that bandwidth is deducted from both locations involved in a call, not only one
- CUCM checks if “Automated Alternate Routing Enable” service parameter is set to true (it’s false by default). This step is often forgotten, so keep in mind that without this parameter AAR won’t be invoked and you will get reorder tone
- The originating Device’s AAR group is compared to Destination Line’s AAR group, in order to determine the called number prefix (configured in the AAR group settings)
- Then, the destination line’s external phone number mask is concatenated to the prefix determined in 2.-, so the called number finally is [Group Prefix] + [Ext Phone Num Mask]
- Following, the calling device AAR CSS is used to route the call over the PSTN, if a route pattern is matched, the call goes out, most likely from the originating device’s local gw, and the call finally rings the desired internal number
By the introduction of CUCM 7.0 features as + Dialing, Local Route Group and Called Number Transformation Patterns the AAR configuration is now much more straightforward than it was before and scales very well as the cluster size/locations grow, so that, some changes in configuration can be done (you still have the possibility to do it in the old fashion):
- Set the External Phone Number Mask or AAR Destination Mask (the latter will win) for phone lines, voicemail pilots, etc to the E.164 format
- Create an unique AAR group and assign them to the phone lines, phone devices will inherit the line’s AAR Group configuration
- Create a CSS with a PT_AAR and assign it to phone devices in all locations
- Configure an unique route pattern \+! In AAR_PT pointing to the Standard Local Route Group’s Route List, in that way all the AAR calls are originated from the local gw of the calling device
- Calls will get to the gw with e.164 formatting, so you have to configure Called Pattern Xform Patterns to remove the + sign and prefix the proper numbers to match the PSTN requirement for every site
You can find more information about this feature in the CUCM SRND, Dial Plan Section.
I Hope this post has helped in your CCIE Voice studies, and if you have any queries, please write!!
–
Otto Sanchez – CCIE #25592 (Voice)
Support Engineer – IPexpert, Inc
Web: http://www.ipexpert.com/
Tags: AAR, ccie voice, CUCM
Hi Otto. thanks for the post and details on new added feautre. I have a queston though and this is related to general AAR.
when the call is finally routed using AAR CSS out to originating site’s GW ( lets say HQ and GW is MGCP) and finally reaches to destination site’s GW ( lets say BR1 and GW is MGCP ), since the destination GW ( BR1) is a MGCP GW and is controlled by CUCM in HQ site connected to BR1 using IP WAN, the call actually comes to CUCM through BR1 MGCP GW and is routed to BR1 Ph1 over same IP WAN so the the logic of unsufficient bw would restrict the call again to go to BR1 Ph… am i right ?
i am kind of confused how the call will actually be routed to Br1 phone after it reached BR1 GW over PStn..
Hi Satish!
I think you might have misunderstood how AAR works and what it is used for.
In your described call scenario it would look like this.
1. HQ phone 1 call to BR1 phone 1.
2. Call Admission Control (CAC) checks if there are enough BW to place the call over the WAN. In the case of that the answer to this is no this will happen.
3. CUCM will check if AAR is enabled.
4. Then AAR group is checked, if they are different the AAR mask will be used as a number prefix.
5. EPNM or AAR destination mask will be checked, the later has precedence.
6. Result from step 4 and 5 will be concatenated in that order. For example [Group Prefix] + [Ext Phone Num Mask].
7. The once internal call will be rerouted out to the PSTN over the local VGW. In your case it would use the gateway at HQ for the call out to PSTN.
8. Then the call would come in on the BR1 VGW as an external call and that would deliver the call to the local BR1 phone 1.
In other words the RTP stream will never traverse the WAN, it will be in the form of this illustration.
HQ Ph1 -> HQ VGW ->PSTN (in case of E1/T1 of course no RTP here) -> BR1 VGW – BR1 Ph1
This is very much as Otto has described it. Please read up on the concept and try it out for your self and I’m sure that it will become clearer.
Sincerely
Roger Källberg
CCIE #26199 (Voice)
Hi,
I see if we have + dialing, we can do AAR with only one group
Only the TEHO calls fail to go through WAN
How can I let the TEHO calls to count from the number of allowed calls , and if the bandwidth not available and the call will be rerouted , how the calling phone know the new called number that the other site gw not have EPNM as the phones
Thanks