Many parameter settings require the restart of the Call Manager service.
It is a good practice when changing or setting service parameters, to restart the call manager service to assure the new setting takes effect.
What then would prevent AAR from working? I had our vendor review my config.
1. Have AAR group setup
2. Have PT setup for AAR-PT
3. Have CSS setup for AAR-CSS
4. Have an LD route pattern under AAR-PT
5. AAR-PT is only PT in the AAR-CSS
6. AAR-CSS is applied to device level
7. Correct AAR group setup on line level
CAC is working with showing on phone screen that there is not enough bandwidth etc. Call never goes out. Call route is from remote office IP phone to Hub home office IP phone.
do all phones have the external phone number mask?
are you doing this within phones in the same cluster?
look into a CUCM trace, you will see if the call is attempted and what is dialed.
are you adding the necessary prefix to dial thru PSTN?
if this helps, please rate
Yes all phones have an external phone mask
Yes phones are in same cluster, different locations physically and in CM
I never see the call attempted. In CUCM trace the last insert was about the display to the calling party of "Not Enough Bandwith".
You. The AAR group contains a 91 for prefix and long distance. There is a 91[2-9]xx[2-9]xxxxxx in the AAR-PT.
Ensure that the GW is in the correct Location as well, the remote location GWs need to be configured with that "Location" for AAR to work properly.
There is a Service Parameter on Callmanager called "Stop Routing on Out of Bandwidth Flag" by default this is set to False, change this to True and it may resolve the problem.
That is one I haven't heard of. I have a case open with Cisco and that is more than they have come up with. I will run this by them. I am rating this one for just thinking outside the box here....Will follow-up on what happens...
We are using a single cluster with separate sites for locations to enable AAR. I read the description, and it has to do more with trunks and between clusters, which doesn't apply here.
Stop Routing on Out of Bandwidth Flag: This parameter determines routing behavior for calls through intercluster trunks when not enough bandwidth exists. Valid values specify True or False. When the parameter is set to True and a call that is being routed to a remote Cisco cluster through a route list is released by a remote Cisco CallManager because of the insufficient bandwidth of a destination device at the remote cluster, a local Cisco CallManager will stop routing the call to the next device in the route list. When the parameter is set to False, the local Cisco CallManager will route the call to the next device. An associated Location specifies the bandwidth of the device.
This is a required field.
My previous post should have read:-
Stop Routing on Out of Bandwidth Flag, default = true, try changing it to false, not the other way round.
I don't believe this only applies to ICTs.
Thanks for my first rating.
Hi Just come across this by chance in 5.1(1) release notes, are you using a remote Gateway for AAR.
Automated Alternate Routing (AAR) Limitation with Remote Gateways
AAR exhibits the limitation that calls routed over a remote gateway during a high-bandwidth situation
fail, and the calls cannot be routed over the local gateway when AAR is used. This functionality is
important to customers who use Tail-End Hop Off (TEHO) for toll bypass.
Use a specific partition for the TEHO in question.
In the following example, headquarters (HQ) has area code 408 and the Branch (BR1) has area code 919.
Configure as follows:
1. Create theTehoBr1forHQPt partition and assign this partition to the calling search space (CSS) of
the HQ devices with a higher priority than the regular PSTN access uses.
2. Create the TehoBr1forHQRL route list and add the BR1 gateway route group to this route list as the
first option and the HQ gateway as the second option.
3. Apply called party modification within the route list. In this case, apply predot called party
modification for the BR1 route group, and apply predot and prefix 1919 called party modification
for the HQ route group.
4. Ensure that the gateway does not perform called party modification.
5. Create a route pattern in the TehoBr1forHQPt partition.
6. Ensure that no called party modifications are applied in the route pattern.
In an out-of-bandwidth situation, after Cisco Unified CallManager tries to allocate the first route group
for TEHO (BR1 route group), Cisco Unified CM retries the second route group, at which point the
system strips the 91919 string and replaces it with the 1919 string, which is suitable for long-distance
dialing. Because the string is configured for use by the local gateway, less rerouting takes place.
AAR works on a per-external-phone-number-mask basis and cannot be processed for an external PSTN
number because the system does not know the phone number mask of the PSTN number. This
workaround provides AAR functionality and improves network resiliency.