New AAR Config not working

[Click Click]

System version: 7.1.3.32900-4

Hello

We have recently setup a h.323 gateway to a remote site and calls are flowing to/from the remote site via the WAN. I have now attempted to setup AAR however this doesn't work, Can you help?

I am setting the remote location audio bandwidth to 1 to simlate the test. When i make the test call i get the following error "not enough bandwidth"

i have done the following config as per the instruction i have understood from Cisco

1. Enabled Automated Alternate Routing Enable to true in service parameters

2. created the locations (UK & US)

3. created the aar_css for PSTN access

4. created the aar groups with the pstn dialling rule

5. added the UK phone to the UK AAR Group and given the AAR CSS access to the PSTN

6. added the line 1 (in a udp) to the UK AAR Group.

7. added the US aar group to the remote h.323 gateway

Is there anything i am missing?  i can supply more detail if it helps?

Thanks in advance

C.

[Joseph Martini]

One tip is to make sure you apply the AAR group to the line, not the device.  The device level AAR group setting is only used for device mobility (roaming).  You have to have the AAR group configured on the line for AAR to be invoked when in a not enough bandwidth scneario.

[Click Click]

Hello Joe and thank you for the reply

i do have the aar config applied to the line as well as to the phone. We use EM so the line exists on the udp

AAR Destination Mask = blank

AAR Group = UK_Cluster_AAR

Retain this destination in the call forwarding history = ticked

Is there anything else i can check?

Thanks

C.

[Click Click]

I should add that the phone just displays not enough bandwidth. It doesn't seem to even attempt to re-route the call.

[Ayodeji Okanlawon]

Click,

Here are the steps to enable AAR.

Check through the lines and see which you are missing. Do you have External number mask configured on the Destination phone?

• 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
  

• 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
  

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Click Click]

• Both phones involved in the call must be registered to CUCM = The remote site is using a non Cisco h.323 gateway/phone system. Does AAR only between cisco devices/clusters?
  

• 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 = ok
  

• 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 = I have already set this to TRUE
  

• 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) = That is how i understand it YES
  

• 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] = AH! I can see that this could be a problem as the remote end is a non Cisco phone system, this could be where it's going worng?
  

• 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
  

• 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 = External Phone Number Mask is set already
  

• Create an unique AAR group and assign them to the phone lines, phone devices will inherit the line’s AAR Group configuration = Done
  

• Create a CSS with a PT_AAR and assign it to phone devices in all locations = Done
  

• 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 = not done as yet
  

• 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 = not done as yet
  

See my comments above. I guess the first question/response would be is AAR only support on cisco cucms/ single clusters?  as stated above. the HQ is using a cucm cluster and the remote end is a 3rd party h.323 gateway connected to an analogue pbx

[Ayodeji Okanlawon · Accepted solution]

Yes AAR is only supported between phones registered to the same CUCM. Yes AAR will only work with cisco devices. The decisions are made as you can see based on information obtained from the calling and called destination devices. If cucm is not aware, it cant invoke AAR

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Click Click]

Thank you for the answer. I will need to seek other ways to redirect calls via the PSTN.  Thank you

[William Bell]

Click,

If I follow the scenario correctly then you have a H323 Gateway configured in CUCM that points to your remote IP-PBX / Phone. If that is the case then you can do the following:

Put H323 GW into a Route Group (e.g. h323_rg)

Put one of your pstn gateways into a Route Group (e.g. pstn_rg)

Put h323_rg and pstn_rg into a route list (e.g. remotePBX_rl)

Associate the route list remotePBX_rl to the route pattern you want to send to the foreign system.

Use your locations-based CAC mechanism/test and place a call. If you set the H323 GW to BW 1kbps then what should happen is the CUCM call processing should route around the "problem" and go to the next route group in the route list (i.e. pstn_rg) and send the call out of the PSTN.

The example above is simplistic and doesn't reflect your environment. You could also use SLRG to allow remote site phones to prefer their own gateway (just like you can with AAR).

Also, the example above is focused on solving the CUCM-to-Non_CUCM call setup path. For the reverse direction (ingress call) the location setting should still initiate a call setup failure and CUCM will send the failure back to the foreign system. It is up to the foreign system to handle the error gracefully. You can look at traces to see what is sent back and then figure out if the foreign system can handle.

HTH

-Bill (http://ucguerrilla.com)