This topic describes the interactions of globalized call routing and local route groups with Cisco Unified Communications Manager Device Mobility.
Device Mobility Without Local Route Groups and Globalized Call Routing
There are two types of device pool settings for Device Mobility:
- Roaming-sensitive settings (location, region, SRST reference, MRGL, etc.) are always updated when device roams to different physical locations.
- Device Mobility-related settings (device CSS, AAR CSS, and AAR group) are updated based on device mobility group:
- Different device mobility group:
- No update of device CSS, AAR CSS, and AAR group
- No changes to dial rules, but use of home gateway
- Same device mobility group:
- Update of device CSS, AAR CSS, and AAR group
- Use of roaming gateway but changes to dial rules
- Required only when gateway selection is based on CSS (that is, local route group and globalized call routing are not used)
- Different device mobility group:
Local route groups were introduced in Cisco Unified Communications Manager Version 7. When local route groups (and globalized call routing, which utilizes local route groups) are not used or supported, Device Mobility is typically implemented as follows:
- Roaming-sensitive settings: These settings are always updated when the device roams between different physical locations. These settings are location, region, Cisco Unified SRST reference, MRGL, and other parameters that do not affect the selection of the PSTN gateway or the local rules.
- Device Mobility-related settings: These settings can be applied in addition to the roaming-sensitive settings (which means that a phone has to roam between different physical locations). The most important Device Mobility-related settings are device CSS, AAR CSS, and AAR group. The configuration of the device mobility group should determine your decision about whether to apply the Device Mobility-related settings.
- If the device roams between different device mobility groups, the Device Mobility-related settings are not updated with the values that were configured at the roaming device pool. This configuration has the advantage that users do not have to adapt to different dial rules between home and roaming location (if they exist). The disadvantage is that all PSTN calls will use the home gateway, which can lead to suboptimal routing.
- If the device roams within the same device mobility group, the Device Mobility-related settings are updated with the values of the roaming device pool. This configuration has the advantage that all PSTN calls will use the local (roaming) gateway, which is typically desired for roaming users. However, the users will have to use to the local dial rules.
If TEHO is used, there are no suboptimal paths when using Device Mobility with different device mobility groups. However, when local route groups and globalized call routing are not used, TEHO implementation can be very complex, especially when local PSTN backup is desired and when TEHO is implemented in international deployments.
In summary, unless TEHO is used, the implementation of Device Mobility without globalized call routing leads to this situation: Either the home gateway must be used (when allowing the user to use the home dial rules) or the user is forced to use the dial rules of the roaming site (in order to use the local gateway of the roaming site).
Advantages of Using Local Route Groups and Globalized Call Routing
Device Mobility benefits from globalized call routing and local route groups, especially when implemented in international environments.
Device Mobility benefits from globalized call routing and local route groups:
- Updates of roaming-sensitive settings
- Local route group is a roaming-sensitive setting.
- Globalized call routing and local route groups allow the combination of two features, which are exclusive otherwise:
- Roaming gateway can be used.
- Home dial rules can be used.
- No updates of device mobility-related settings (device CSS, AAR CSS, and AAR group) are required:
- Functionality of device-level CSS (device-line approach) is replaced by local route group in route list
- Different AAR groups and AAR CSS are not required
- Eliminates need for device mobility groups
When Device Mobility with globalized call routing is used, there are no changes in the roaming-sensitive settings. Their application always makes sense when roaming between sites. They have no influence on the gateway selection and the dial rules that a user must follow.
The dial plan-related part of Device Mobility, however, changes substantially with globalized call routing. It allows a roaming user to follow the home dial rules for external calls and nevertheless utilize the local gateway of the roaming site.
This situation is possible because globalization of localized call ingress at the phone occurs. This function is provided by the line CSS of the phone. It provides access to phone-specific translation patterns that normalize the localized input of the user to global format. The device CSS that was used for gateway selection is obsolete, because gateway selection is now performed by the local route group feature.
The AAR CSS and AAR group that are configured at the device level can be the same for all phones as long as the AAR number is always in global format. (You can ensure that the AAR number is always in global format by configuring either the external phone number mask or the AAR transformation mask to E.164 format.) In this case, no different AAR groups are required, because there is no need for different prefixes that are based on the location of the two phones. Further, there is no need for a different AAR CSS, because the gateway selection is not based on different route lists (referenced from different route patterns in different partitions). Instead, the gateway selection is based on the local route group that was configured at the device pool of the calling phone.
In summary, when using globalized call routing, Device Mobility allows users to use local gateways at roaming sites for PSTN access (or for backup when TEHO is configured) while utilizing their home dial rules. There is no need to apply different device CSS, AAR CSS, and AAR groups, and hence, device mobility groups are no longer required.
Example: No Globalized Call Routing with Different Device Mobility Groups
The figure shows an example of Device Mobility with different device mobility groups in an environment where globalized call routing is not implemented. Also, gateway selection is performed by the device CSS of the IP phone.
In the example, there are two sites. The main site (HQ in the figure) is in Europe, the branch site (BR in the figure) is in the United States. Separate route patterns (representing the different dial rules) are configured in different partitions. The CSS of the HQ phones provides access to the HQ gateway. The CSS of the BR phones provides access to the BR gateway.
Device Mobility is configured with different device mobility groups. This configuration allows BR users who are roaming with their phones to the HQ to use the home dial rules. The device CSS is not updated by Device Mobility, and therefore, the CSS still provides access to the BR route pattern (9.@). However, as a consequence, the BR gateway is used for all PSTN calls.
Example: No Globalized Call Routing with Same Device Mobility Group
The figure shows an example of Device Mobility with identical device mobility groups in an environment where globalized call routing is not implemented. Also, gateway selection is performed by the device CSS of the IP phone.
This example is identical to the previous example with one exception: This time the device mobility group of the home and the roaming device pool are the same.
When a BR user roams to the HQ, the device CSS of the phone is updated with the device CSS of the roaming device pool. In the example, CSS BR is changed to HQ. As a consequence, the phone has access to the HQ partition, which includes PSTN route patterns in EU dialing format (0.!).
Therefore, the roaming user has to follow EU dial rules. Calls to 9.@ are not possible anymore. However, this configuration allows the BR user to use the HQ gateway when roaming to the HQ.
Example: Globalized Call Routing
The figure shows an example of Device Mobility in an environment where globalized call routing is implemented. Also, gateway selection is performed by the local route group feature.
The example in the figure is based on the previous scenario: HQ is in Europe, BR is in the United States. A BR user roams to Europe.
However, in this example, globalized call routing has been implemented. Therefore, the (line) CSS of the BR phones provides access to translation patterns that convert localized call ingress at the phone (NANP format) to global E.164 format. EU phones have access to translation patterns that convert EU input to global E.164 format.
A single PSTN route pattern (\+!) is configured; it is in a partition that is accessible by all translation patterns.
When a BR user roams to the HQ, the line CSS is not modified; no device CSS is configured at the phone or at the device pool. The device mobility groups are also not set (or are set differently).
As a result, there is effectively no change in matching the translation patterns: The BR user still uses NANP dial rules (like at home). The number is converted to international format by translation patterns and matches the (only) PSTN route pattern. The route pattern refers to a route list that is configured to use the default local route group. The default local route group is taken from the roaming device pool. Therefore, if the phone is physically located in the BR office, the local route group is BR; if the phone is roaming to the HQ site, the local route group is HQ. As a result, the local gateway is always used for a PSTN call.
If TEHO was configured, there would be a TEHO route pattern in E.164 format with a leading plus (+) sign. The TEHO pattern would refer to a site-specific route list to select the correct gateway for PSTN egress. The backup gateway would then again be selected by the local route group feature.