This topic describes how to implement AAR in Cisco Unified Communications Manager.
AAR allows calls to be rerouted through the PSTN by using an alternate number when Cisco Unified Communications Manager blocks a call due to insufficient location bandwidth. With AAR, the caller does not need to hang up and redial the called party. Without AAR, the user would get a reorder tone and the IP phone would display “Not enough bandwidth.”
AAR applies to centralized call-processing deployments. For instance, if a telephone in a company headquarters calls a telephone in branch B and the available bandwidth for the WAN link between the branches is insufficient (as computed by the locations mechanism), AAR can reroute the call through the PSTN. The audio path of the call would be IP-based from the calling phone to its local (headquarters) PSTN gateway, TDM-based from that gateway through the PSTN to the branch B gateway, and IP-based from the branch B gateway to the destination IP phone.
AAR is transparent to users. It can be configured so that users dial only the on-net (for example, four-digit) directory number of the called phone. (No additional user input is required to reach the destination through an alternate network such as the PSTN.)
In the example that is shown in the figure, a call is placed from Phone A to Phone B, but the locations-basedCAC denies the call due to insufficient bandwidth. Cisco Unified Communications Manager now automatically composes the required route pattern to reach Phone B via the PSTN and sends the call off-net.
This subtopic describes the characteristics of AAR.
- Provides a fallback mechanism for calls denied by CAC:
- Reroutes calls over PSTN.
- Works only for intracluster CAC (intracluster enhanced location and RSVP-enabled locations).
- Works only for calls placed to internal endpoints.
- Alternate number is composed of dialed directory number, a prefix configured per AAR source and destination group, and the external phone number mask of the called device:
- AAR destination mask can be configured per device (also known as Call Forward No Bandwidth [CFNB]) to reroute calls to other phone numbers, such as cell phones.
- Forward to voicemail can be configured per device to reroute calls to voicemail.
AAR provides a fallback mechanism for calls that are denied by locations-based CAC or RSVP-enabled locations-based CAC by rerouting calls over the PSTN in the event of CAC failure.
AAR works only for calls that are placed to internal directory numbers. AAR does not apply to calls that are placed to route patterns or feature patterns such as Meet-Me or Call Park. However, it does work for hunt pilots and CTI ports. These entities can be configured with an AAR group and an AAR CSS.
The alternate number that is used for the PSTN call is composed of the dialed directory number, a prefix that is configured per AAR source and destination group, and the external phone number mask of the called device.
Alternatively, calls can be routed to voice mail, or you can configure an AAR destination mask for each device that allows any number to be used for the rerouted call. The number that is specified at the AAR destination mask is also known as the CFNB destination.
AAR is a fallback mechanism for calls that are denied by locations-based CAC or RSVP-enabled locations-based CAC. AAR does not apply to calls that are denied by gateways because the available or administratively permitted number of channels is exceeded, or to calls that have been rejected on trunks (for example, on gatekeeper-controlled H.225 or intercluster trunks). If such calls fail (for whatever reason), fallback mechanisms are provided by route lists and route groups.
AAR Example Without Local Route Groups and Globalized Numbers
The figure shows an example of AAR when globalized call routing and local route groups are not used.
There are two sites, one in the United States and the other one in Germany (country codes 1 and 49). At site 1 (country code 1) the access code is 9. At site 2 (country code 49) the access code is 0. Both countries use 10-digit numbers. There are two route patterns (9.@ for site 1 and 0.! for site 2). Each route pattern is in a site-specific partition, and the phones use site-specific CSSs.
From the perspective of AAR, U.S. phones are configured with a 10-digit external phone number mask, and phones in Germany also use national format for the external phone number mask. U.S. phones are in AAR group U.S., and German phones are in AAR group DE. AAR prefixes are configured in this way:
- Prefix from AAR group U.S. to AAR group DE: 901149
- Prefix from AAR group DE to AAR group U.S.: 0001
The AAR CSS of the U.S. phones has access to the 9.@ route pattern; the AAR CSS of German phones has access to the 0.! route pattern.
When a call from a U.S. phone to a German phone is not admitted because there is no available bandwidth, the external phone number mask of the German phone is merged with the DN of the phone (in this case, the result is 691253001). Then the prefix 901149, which is configured from AAR group U.S. to DE, is appended. The resulting call to 901149691253001 is processed by the 9.@ route pattern, which refers to the U.S. gateway.
In the other direction, an AAR call from a German phone to a U.S. phone composes a dial string of 00015115552001, which is the format that is used for international calls to the United States. It matches the 0.! route pattern and is sent out using the German gateway.
In summary, this two-site example requires two route patterns in different partitions, two AAR CSSs, and two AAR groups. In a large, worldwide deployment with lots of different numbering plans, the configuration of AAR groups can be relatively complex.
AAR Example with Local Route Groups and Globalized Numbers
The figure shows an AAR example where globalized call routing and local route groups are used.
If the AAR destination mask is entered in the globalized form, and if every AAR CSS is able to route calls to destinations in the globalized form, then system administrators can forego the configuration of AAR groups, because their sole function is to determine which digits to prefix based on the local requirements of the PSTN access of the calling phone to reach the specific destination. With globalized call routing, Cisco Unified Communications Manager can route calls to the PSTN in E.164 format with a plus (+) prefix. When you configure the external phone number mask in this format, no prefixes are required for AAR. To localize the called- and calling-party numbers, implement global transformations for each egress PSTN gateway (like for normal PSTN calls).
Without local route groups, the AAR CSS is used to route the call through the colocated gateway of the calling phone by matching a site-specific route pattern that refers to a site-specific route list, route group, and gateway. When local route groups and globalized call routing are implemented, the egress gateway does not need to be selected by site-specific AAR CSS, because the egress gateway is determined by the local route group feature.
In summary, when you are using globalized call routing with local route groups, AAR implementation is extremely simple: Only a single AAR CSS and AAR group are required and applied to all phones, regardless of their location.
In the example, all phones are in the same AAR group (System). No prefix is configured for calls within this single AAR group. There is a single route pattern in E.164 format: (\+!). The route pattern refers to the only configured route list, which is configured to use the local route group. Each gateway is referenced from a site-specific route group. U.S. phones use a U.S.-specific device pool with the local route group set to U.S., and German phones use a device pool specific to their country, where the local route group refers to the DE route group. The external phone number mask in globalized format is +15115222xxx at U.S. phones and +4969125xxxx at German phones. The AAR CSS is the same for both phones and provides access to the \+.! route pattern.
When a call from a U.S. phone to a German phone is not admitted because of no available bandwidth, the external phone number mask of the German phone is merged with the directory number of the phone (in this case, the result is +49691253001). No AAR prefix is added, so a call is placed to that number. It matches the \+.! route pattern, and the local route group is to be used. Therefore, the call is sent to the U.S. gateway, where the called number can be localized, using called-party transformation (that is, the number is changed to 49691253001 with a number type of international) settings that are configured at the gateway.
The same thing happens for calls in the other direction. As a result, +15115552001 is called, and after the called number is localized at call egress—again provided by global transformations at the gateway—a call with a number type of international is placed to 15115552001, this time through the German gateway.
This subtopic discusses important considerations when you are implementing AAR.
- AAR supports these call scenarios:
- Call originates from an IP phone within one location and terminates at an IP phone within another location.
- Incoming call through a gateway device within one location terminates at an IP phone within another location.
- AAR does not work with SRST:
- AAR is not activated by WAN failure.
- AAR requires CAC failure.
- Use of globalized call routing simplifies AAR implementation in international deployments.
- AAR does not support CTI route points as the origin or destination of calls.
- AAR does not work to Cisco Extension Mobility users that roam to different sites.
AAR supports these call scenarios:
- A call originates from an IP phone within one location and terminates at an IP phone within another location.
- Incoming call through a gateway device within one location terminates at an IP phone within another location.
AAR does not work with SRST. AAR is activated only after a call is denied by CAC, not by WAN failures.
Using globalized call routing simplifies the implementation of AAR substantially, especially in international deployments.
AAR does not support CTI route points as the origin or destination of calls, and AAR is not compatible with Cisco Extension Mobility for users who roam to different sites.
When TEHO is used, it is important to configure AAR so that the local gateway is always used for calls that are rerouted by using AAR. Use of the local gateway automatically occurs when you use local route groups. When you do not use local route groups, you must configure an AAR CSS so that the local gateway is used for AAR calls. If the AAR CSS refers to the TEHO gateway, AAR calls will fail because the call leg to the (remote) PSTN gateway has the same issue that the initial call had. The call must go over the IP WAN, which typically means that it goes out of the location of the originating phone. However, the call cannot go over the IP WAN because no bandwidth is left for the location. Lack of bandwidth is the reason why the initial called resulted in a CAC failure.
AAR Configuration Procedure
The implementation of AAR includes these steps.
- Configure AAR service parameters (Cisco CallManager service).
- Configure partitions and CSSs.
- Configure AAR groups.
- Configure phones for AAR:
- Apply AAR CSS and (source) AAR group to IP phones.
- Configure IP phone directory numbers:
- Apply (destination) AAR group.
- Set individual AAR destination mask (CFNB).
- Forward to voicemail if no bandwidth is available.
You need to precisely design partitions and AAR CSSs. The AAR CSS of the calling device must include the partition that is necessary to route the redirected call. The call is routed to a number that is composed of the destination directory number, external phone number mask, and AAR prefix (according to the AAR group configuration). If you configure an individual AAR destination mask or forward to voicemail, the AAR CSS must provide access to these numbers (numbers that are composed of the called directory number and AAR destination mask or voicemail pilot number).
As mentioned earlier, in globalized call routing, AAR configuration is simpler when you use the globalized format at the external phone number mask.