Implementing Automated Alternate Routing
While not a call admission control mechanism itself, Automated Alternate Routing cannot function without one, be it location-based or RSVP. Automated Alternate Routing only takes effect when a call is denied for bandwidth reasons, and will not reroute calls if they were rejected by the gateway for any other reason.
Getting ready
This recipe assumes Automated Alternate Routing is enabled as described in the previous recipe.
How to do it...
To implement Automated Alternate Routing, perform the following:
- First, activate the necessary services for AAR (System | Service Parameters).
- Select a server from the Server drop-down menu. This should be a server running the CallManager service.
- Select the Cisco CallManager service from the Service drop-down menu as shown:
- After selecting the CallManager service from the drop-down, the page reloads and the associated parameters are seen.
- Near the bottom , the section titled Clusterwide Parameters (System | CCM Automated Alternate Routing), change the Automated Alternate Routing Enable Required Field to True.
- Click Save.
- Next, create a calling search space that will be used exclusively for AAR (Call Routing | Class of Control | Calling Search Space).
- Click Add New to add a new calling search space.
- Give it an appropriate name and assign the partition containing the route patterns that AAR will use to route the calls. In this example, we use CSS-CallForwardNoBandwidth-AAR and PT-Global-E164, respectively, as shown in the following screenshot:
- Click Save.
- Next, we configure the AAR Group (Call Routing | AAR Group).
- Click Add New to add a new AAR Group.
- Give the group an appropriate Name.
- Click Save.
- Under the section Prefix Digits within AAR-Default, where AAR-Default is the name of the AAR group previously created, configure a Dial Prefix as necessary. More on this shortly.
- Click Save.
- Next, we apply the AAR group to the Device Pool (System | Device Pool).
- Locate the device pool and open the configuration page.
- Under the section Device Mobility Related Information, specify the AAR Calling Search Space and the AAR Group as created previously.
- Click Save.
- Finally, configure the AAR settings under the directory number line settings (Call Routing | Directory Number).
- Locate the directory number for which we are applying AAR settings, and open the configuration page.
- Specify the AAR Destination Mask (typically the full DID, that is, Direct inward dialing) and the AAR Group under the section titled AAR Settings.
- Alternatively, to send AAR calls to voice mail, check the Voice Mail check box. The AAR Group and AAR Destination Mask settings are unnecessary in this case.
- Click Save.
How it works...
When Unified Communications Manager denies a call due to insufficient bandwidth, AAR settings take effect. After the call is denied, the dial prefix from the AAR group is prefixed to the AAR Destination Mask number. Automated Alternate Routing will then take this new number and try to match a route pattern available to it through the calling search space created. The call is then routed normally.
There's more...
Implementing Automated Alternate Routing in an environment with a traditional dial plan can be quite complex, depending on how the platform is configured. The design notes for Automated Alternate Routing are:
AAR Groups define the dialing relationship between groups, allowing us to configure specific dial prefixes that may be required to route the call properly to the PSTN via the local gateway.
When utilizing an E.164 compatible dial plan, generally only one AAR Group is required as demonstrated in the How to do it... section of this recipe. This greatly simplifies configuration and is expandable to an infinite number of sites.
For systems that use a more traditional dial plan, an AAR Group is generally required for each site. This is necessary to ensure that the number is formatted correctly before it is handed off to the gateway to be routed to the PSTN.
Depending on the environment, additional partitions may be required to support AAR, typically where an E.164 compatible dial plan is not being utilized.
The sole purpose of an AAR partition is to define the route patterns, which can be used to route the call outside to the PSTN.
As with partitions, the number of calling search spaces required depends greatly on the dial plan, this will generally coincide with the number of partitions required for AAR.
When using logical call routing with an E.164 compatible dial plan, no additional route patterns are typically required. Calls will match the \+! pattern and be routed normally out of the local gateway.
If the dial plan is not E.164 compatible, the number of new route patterns required depends heavily on the gateway. In the case where the called and the calling party transformations are not available, the route patterns must format the call to be accepted by the gateway. Depending on how the Off-Net route patterns are configured, additional route patterns may not be required. Specifically, when each site has site-specific route patterns with a site-specific partition, the site-specific partition can be added to the calling search space.