Cisco Unified Communications Manager Features and Services Guide, Release 9.0(1)
Local route groups
Download this chapter
Local route groupsLocal route groups
Download the complete book
Cisco Unified Communications Manager Features and Services Guide, Release 9.0(1)Cisco Unified Communications Manager Features and Services Guide, Release 9.0(1) (PDF - 20 MB)
 Feedback

Local route groups

This chapter provides information about local route groups.

Configure local route groups

The Local Route Group feature helps reduce the complexity and maintenance efforts of provisioning in a centralized Cisco Unified Communications Manager deployment that uses a large number of locations. The fundamental breakthrough in the Local Route Group feature comprises decoupling the location of a PSTN gateway from the route patterns that are used to access the gateway.

The Local Route Group feature provides the ability to reduce the number of route lists and route patterns that need to be provisioned for implementations of Cisco Unified Communications Manager where each of N sites needs to have access to the local gateways of the other N-1 remote sites. One such scenario occurs with Tail End Hop Off (TEHO).

Perform the following steps to configure the Local Route Group feature.

Procedure
    Step 1   Review the interactions and restrictions for this feature.
    Step 2   If you have not already done so, activate the Cisco CallManager service in Cisco Unified Serviceability.
    Step 3   Use the Call Routing > Route/Hunt > Route List menu option in Cisco Unified Communications Manager Administration to configure a local route list that contains the Standard Local Route Group as a member of the route list.
    Step 4   Use the System > Device Pool menu option in Cisco Unified Communications Manager Administration to configure the Local Route Group setting for the device pools in the Cisco Unified Communications Manager implementation. For each device pool that you configure, specify a route group to use as local route group for that device pool. For each device pool, users may also configure the Called Party Transformation CSS for the devices in that device pool.
    Step 5   If the dial plan is not globalized and the Local Route Group needs to use transformation patterns for called party, use the Device > Gateway and Device > Trunk menu options in Cisco Unified Communications Manager Administration to configure the gateways and trunks in each location.

    For each device that you want to configure for the Local Route Group feature, configure the following fields:

    • Called Party Transformation CSS - Choose a CSS to allow localization of the called party number on the device.
    • Use Device Pool Called Party Transformation CSS - Check this check box to use the Called Party Transformation CSS that is specified by the device pool to which this device belongs. If the check box is left unchecked, the Called Party Transformation CSS specified for the device gets used.
    Step 6   Use the Call Routing > Transformation Pattern > Called Party Transformation Pattern menu item in Cisco Unified Communications Manager Administration to configure the called party transformation pattern for the digits before a call is routed out through a gateway.
    Step 7   Use the Call Routing > Route/Hunt > Route Pattern menu item in Cisco Unified Communications Manager Administration to configure the route patterns to use route lists that are configured to use the Standard Local Route Group.
    Step 8   Use the Call Routing > Route Plan Report menu option in Cisco Unified Communications Manager Administration to generate and view the route plan report for your implementation. Check the route plan report to verify that the provisioning that you performed is correct for your Local Route Group configuration.
    Related References
    Related Information

    Local route groups feature

    The Local Route Group feature helps reduce the complexity and maintenance efforts of provisioning in a centralized Cisco Unified Communications Manager deployment that uses a large number of locations. The fundamental breakthrough in the Local Route Group feature comprises decoupling the location of a PSTN gateway from the route patterns that are used to access the gateway.

    Cisco Unified Communications Manager uses a special Local Route Group that can be bound to a provisioned route group differently based on the Local Route Group device pool setting of the originating device. Devices, such as phones, from different locales can therefore use identical route lists and route patterns, but Cisco Unified Communications Manager selects the correct gateway(s) for their local end.


    Note

    This document uses the term provisioned route group to specify a route group that an administrator configures through use of the Call Routing > Route/Hunt > Route Group menu option in Cisco Unified Communications Manager Administration.

    The Local Route Group feature provides the ability to reduce the number of route lists and route patterns that need to be provisioned for implementations of Cisco Unified Communications Manager where each of N sites needs to have access to the local gateways of the other N-1 remote sites. One such scenario occurs with Tail End Hop Off (TEHO).

    In simple local routing cases, the provisioning gets reduced from N route patterns and N route lists to one route pattern and one route list. In cases with Tail End Hop Off (TEHO), local route groups allow configuration of N route patterns and N route lists instead of N2 route patterns and N2 route lists. Because values for N are now reaching much more than 1000 for larger implementations, enormous scalability savings result.

    Previously, Cisco Unified Communications Manager treated gateways as devices to which multiple patterns are assigned. A tight, somewhat inflexible, binding existed between a gateway and the patterns that Cisco Unified Communications Manager associated with the gateway. When a call was placed, Cisco Unified Communications Manager viewed the situation as "Caller X has dialed some digits. These digits match pattern Y. Pattern Y directly associates with route lists, route groups, and gateways A, B, and C."

    Local route group

    When the administrator adds a new route group to a route list, the Route List Configuration window presents the administrator with all available route groups from which to select. This list includes as its first member the special route group that is named Standard Local Route Group. This local route group specifies a virtual local route group.

    The local route group does not statically get bound to any provisioned route group. The local route group does not display in the Find and List Route Groups configuration window; and, therefore, cannot be deleted or modified. You can, however, add the local route group to any route list; when so added, the local route group serves as a placeholder for a provisioned route group that will later get bound to the local route group dynamically during call setup.

    After you add the local route group to a route list, you can later remove it from that list, or you can modify its search-order places in the list as with any provisioned route group.

    Bind a Provisioned route group to a local route group

    Deferring the binding of a provisioned route group to the local route group until call setup ensures that the desired provisioned route group can be the one that is local to the device that is placing the call. Thus, a device in location X would use a provisioned route group that contains gateways for the location X PSTN while a device in location Y would use a different provisioned group of gateways for the location Y PSTN.

    You need to ensure that each device in the system is provisioned to know its local route group. To avoid specifying this information in the configuration window for each device, because the number of devices can be many thousands, Cisco Unified Communications Manager Administration locates the information in the device pool for the device, because device pools specify common site-specific information.

    The Local Route Group field in the Device Pool Configuration window includes a drop-down list box that lists all available (provisioned) route groups. This list excludes the special Standard Local Route Group name (because only provisioned route groups should be configured for a device pool) but presents the special name, <NONE>, which specifies the first (default) choice. Choose <NONE> if no binding is desired.

    Whenever the default value <NONE> is selected for a device pool, any call that uses a route list that includes the local route group, Standard Local Route Group, gets routed as if the Standard Local Route Group is absent from the list.

    With this mechanism, a call that is placed from any device over a route list that contains the special Standard Local Route Group behaves as follows:

    1. The route list algorithm searches through the list of included route groups, in the designated order, until an unused trunk can be found. (The previous and current implementations do not differ.)
    2. If the search encounters the special Standard Local Route Group, the system automatically replaces this route group with the name of the local route group that is provisioned for the calling device, unless the search encounters one of the following situations:
      • If the provisioned route group specifies <NONE>, the Standard Local Route Group route group gets skipped entirely.
      • If by skipping the Standard Local Route Group in this way, the search ends (that is, the Standard Local Route Group was the last or only route group in the route list), routing aborts, and the user receives reorder tone or an equivalent notification.

    Local route groups mapping

    With local route group mapping, Cisco Unified Communications Manager can treat gateways more like a service. Customers benefit by reducing the efforts of provisioning and maintaining the routes plans from this solution.

    Example

    This example assumes a centralized call model with five managed sites as shown in the following figure. Further sections use this call model to demonstrate the two different manifestations of the Local Route Groups feature as follows:

    • Simple local routing cases in which each site needs to route offnet calls to its local gateways
    • More complex tail end hop off (TEHO) cases
    Figure 1. Managing Local Offnet Access in a Centralized Model

    A Cisco Unified Communications Manager deployment that uses the Local Route Group feature must normalize the called digits through Called Party Transformation to guarantee that an intended destination can be reached.

    Simple local routing

    Simple local routing comprises cases in which each site needs to route offnet calls to its local gateways. Provisioning of route patterns and route lists can get reduced from the need to configure N route patterns and N route lists to a configuration where only one route pattern and one route list are needed.

    For this case further assume that all phones that home to a particular site belong to a single calling search space (CSS) that is unique to that site. For example, phones at the Boulder site belong to the CSS-Bldr calling search space and so forth. The following figure illustrates a possible provisioning of this system without using the Local Route Group feature, so regardless of site, a phone always prefers its local gateway when making an offnet call by dialing 9 followed by a seven-, ten-, or eleven-digit pattern. As more sites get added, each of the columns must include new entries (rows). If N sites exist, you need N different route lists, route patterns, partitions, and calling search spaces.

    Figure 2. Provisioning Local Offnet Access Without Local Route Groups

    In the same implementation, use of the Local Route Group feature allows configuration of a single route list, partition, route pattern, and CSS, regardless of the number of sites, as shown in the following figure.

    Figure 3. Provisioning Local Offnet Access With Local Route Groups

    In this case, the following configuration applies:

    • All phones belong to a single CSS-System calling search space and to a single P-System partition.
    • All phones for a given site belong to a single device pool unique to that site.
    • The Local Route Group field in each device pool identifies the specific route group for that site. In this example, RG-Bldr for Boulder, RG-Rch for Richardson, and so on.

    Thus, the route lists, route patterns, partitions and calling search spaces for this case each get reduced from N to 1. The number of gateways, route groups, and device pools remain N for N sites.

    A new partition, P_System, and a new calling search space, CSS_System, get added for accessing the 9.@ pattern from all sites. The calling search space, CSS_Boulder, can contain both P_Boulder and P_System as well, as can the CSS of the other sites.

    Tail end hop off

    Tail End Hop Off (TEHO) refers to routing long-distance calls across the VoIP network and dropping them off to the Public Switched Telephone Network (PSTN), as a local call, at a remote gateway. In TEHO situations, you can reduce the configuration complexity from the need to configure N2 entities to needing only N entities. The following assumptions for TEHO apply:

    • Each site has a different route pattern and route list for each of the other N-1 sites.
    • For a given site, S, each of the N-1 route lists to another (remote) site has, as first preference, a route group of one or more gateways that are local to that other site followed by, as second preference, a route group that is local to S. Therefore, when sufficient trunking resources are available to honor the first preference, a long-distance call uses a gateway at the remote site to go offnet and thus bypass any tolls; otherwise, the call defaults to a local gateway and incurs toll charges.

    Again, Cisco Unified Communications Manager has an identical routing policy for all sites. The second preference of routing a call through the local PSTN of a site (if the system fails to drop off the call as a local call at the remote PSTN) forces the customer to provision separate instances of all routing information for each site, as illustrated in the following figure. (The figure illustrates the configuration for some of the sites.) Each site has a unique set of route patterns and route lists to each of the other N-1 sites, as well as a generic local route list for all other calls that the remote access codes do not cover. This requirement entails a total of N×(N-1)+N, or N2, route lists and route patterns for the general case.

    Figure 4. Provisioning TEHO Without Local Route Groups

    Using the Local Route Group feature, the N×(N-1) route patterns and route lists that are needed for remote sites reduce to N, and the N local route patterns and local route lists reduce to 1. Overall, the total number of route lists and route patterns decreases from N2 to N+1, and calling search spaces and partitions decrease from N to 1, as illustrated in the following figure.

    Figure 5. Provisioning TEHO With Local Route Groups

    In the previous figure, note the crucial element, which is the use of the Standard Local Route Group as the second choice in each route list. The setting in the device pool of the originating device dynamically determines the actual provisioned route group that gets used during a specific call.

    Called party transformations

    While loose coupling occurs between the enterprise number and the route group/gateway, very tight coupling occurs between the route group/gateway and the patterns that the PSTN expects. If the gateway chosen is in a 7-digit dialing location, the PSTN expects 7 digits; if the chosen gateway is in a 10-digit location, the PSTN expects 10 digits to access local numbers.

    Example 1

    A call gets placed from Dallas; the called number specifies 9.5551212. If the Dallas local gateway is busy or not accessible, assuming that the San Jose gateway is selected, 9.5551212 must be converted to 1 214 555 1212 for the San Jose gateway to dial out.

    In the same example for a Local Route Group case, a call gets placed from Dallas. The called number specifies 9.5551212, so the system must perform the following actions:

    1. Take the digits as dialed by the originator, discard PreDot, and insert the prefix +1 214.
    2. Convert the call number to a globally unique E.164 string (+1 214 555 1212).

    If a San Jose gateway gets selected, the system converts the global string +1 214 555 1212 to 1 214 555 1212; if a Dallas gateway gets selected, the system converts the global string to 214 555 1212.

    See the following figure for an illustration of this example.

    Figure 6. Called Digits Transformation

    Example 2

    A call gets placed from RTP; the called number specifies 5551212. If the RTP local gateway is busy or not accessible, assuming that the San Jose gateway is selected, 5551212 must get converted to 1 919 555 1212 for the San Jose gateway to dial out.

    In the same example for a Local Route Group case, a call gets placed from RTP. The called number specifies 9.5551212, so the system must perform the following actions:

    1. Take the digits as dialed, discard PreDot, and insert the Prefix 91919.
    2. Convert the called number to a global dialing string (9 1 919 555 1212).

    If a San Jose gateway gets selected, the system converts the global string 91 919 555 1212 to 1 919 555 1212; if the RTP gateway gets selected, the system converts the global string to 555 1212.

    System requirements for local route groups

    The following system requirement applies to the local route group feature:

    • Cisco Unified Communications Manager 7.0(1) or later

    Interactions and restrictions

    This section describes the interactions and restrictions for local route groups.

    Interactions

    This section describes how the local route group feature interacts with other Cisco Unified Communications Manager features and applications.

    Device support

    All Cisco Unified Communications Manager device types that are capable of originating a call support support the Local Route Group feature, including the following devices:

    • Skinny devices
    • H.323 devices
    • SIP devices
    • MGCP devices, including all PRI variants, BRI, and MGCP phones
    • CTI devices

    Forwarding

    For forwarded calls, Cisco Unified Communications Manager must use the Local Route Group that is provisioned in the device pool settings that are associated with the redirected party to find the provisioned local route group. Thus, if phone A calls (local) phone B and phone B forwards the call to (remote) phone C, the Local Route Group value from the phone A device pool gets used rather than the corresponding value for phone B.

    Supplementary services

    Many supplementary services can originate calls. When this happens, the local route group gets skipped.

    The following features can initiate calls:

    • CallBack
    • MWI
    • Mobility (FollowMe)
    • Path Replacement

    If by skipping the Standard Local Route Group route group, the search ends (that is, the Standard Local Route Group represents the last or only route group in the route list), routing aborts.

    The following features can redirect calls:

    • Barge
    • CallBack
    • Call Park
    • Conference
    • Directed Call Park
    • Forwarding
    • Immediate Divert
    • MeetMe Conference
    • Call Pickup

    As explained in the Forwarding, Cisco Unified Communications Manager uses the Local Route Group that is provisioned in the device pool settings that are associated with the redirected party to find the provisioned local route group.

    Route plan report

    The Route Plan Report displays the route details, such as route list, associated route groups, and trunks/gateways, including the special Standard Local Route Group route group. An example follows.

    Example of Route Plan Report Display for Route Patterns With No Local Route Group

    BoulderRouteList

    |__ BoulderRG

    __BoulderGW1

    |__BoulderGW2

    Example of Route Plan Report Display With Local Route Group

    SystemRouteList

    |__Standard Local Route Group

    Cisco Unified Mobility

    For Single Number Reach calls to a remote destination, the device pool of the originating calling party determines the selection of the Standard Local Route Group.

    Restrictions

    Review this section for applicable restrictions before you configure local route groups.

    Mixed route lists

    You cannot insert SIP route groups and Q.SIG route groups into a route list at the same time. With the Local Route Group feature, this mixed route list rule cannot get enforced during provisioning because the binding between the Standard Local Route Group and a provisioned route group occurs dynamically during the call setup. Therefore, some Q.SIG related features may not be available. The binding from Standard Local Route Group to a Q.SIG route group should be avoided.

    Install and activate local route groups

    After you install Cisco Unified Communications Manager, Release 7.0(1) or later, you can configure local route groups.

    Configure local route groups

    This section contains information about local route group configuration.


    Tip

    Before you configure local route groups, review the configuration summary task for this feature.

    Related Tasks

    Set the local route group service parameters

    The Local Route Group feature does not require the configuration of any additional service parameters.