Table Of Contents

Local Route Groups

Configuration Checklist for Local Route Groups

Introducing Local Route Groups

Local Route Group

Binding a Provisioned Route Group to a Local Route Group During a Call

Routing with Local Route Groups

Simple Local Routing

Tail End Hop Off

Called Party Transformations

System Requirements for Local Route Groups

Interactions and Restrictions

Interactions

Supported Devices

Forwarding

Other Supplementary Services

Route Plan Report

Cisco Unified Mobility

Restrictions

Mixed Route Lists

Installing and Activating Local Route Groups

Configuring Local Route Groups

Setting the Local Route Group Service Parameters

Related Topics

Local Route Groups

---

This chapter provides the following information about local route groups:

•Configuration Checklist for Local Route Groups

•Introducing Local Route Groups

•Routing with Local Route Groups

•Simple Local Routing

•Tail End Hop Off

•Called Party Transformations

•System Requirements for Local Route Groups

•Interactions and Restrictions

•Installing and Activating Local Route Groups

•Configuring Local Route Groups

•Setting the Local Route Group Service Parameters

•Related Topics

Configuration Checklist for 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).

Table 30-1 lists the tasks that you perform to configure the Local Route Group feature. For more information on the local route group feature, see the "Introducing Local Route Groups" section and the "Related Topics" section.

Table 30-1 Configuration Checklist for Local Route Groups 

Configuration Steps		Related Procedures and Topics
Step 1	Review the interactions and restrictions for this feature.	Interactions Restrictions
Step 2	If you have not already done so, activate the Cisco CallManager service in Cisco Unified Serviceability.	Cisco Unified Serviceability Administration Guide
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.	Route List Configuration, Cisco Unified Communications Manager Administration Guide
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.	Device Pool Configuration, Cisco Unified Communications Manager Administration Guide
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.	Gateway Configuration, Cisco Unified Communications Manager Administration Guide Trunk Configuration, Cisco Unified Communications Manager Administration Guide
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.	Called Party Transformation Pattern Configuration, Cisco Unified Communications Manager Administration Guide
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.	Route Pattern Configuration, Cisco Unified Communications Manager Administration Guide
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.	Route Plan Report, Cisco Unified Communications Manager Administration Guide

Introducing 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.

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 N² route patterns and N² 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."

The following subsections explain the details of provisioning local route groups and provide example scenarios:

•Local Route Group

•Binding a Provisioned Route Group to a Local Route Group During a Call

•Routing with Local Route Groups

•Called Party Transformations

Additional Information

See the "Related Topics" section.

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.

Additional Information

See the "Related Topics" section.

Binding a Provisioned Route Group to a Local Route Group During a Call

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.

Additional Information

See the "Related Topics" section.

Routing with Local Route Groups

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 Figure 30-1. 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 30-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.

Additional Information

See the "Related Topics" section.

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. Figure 30-2 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 30-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 Figure 30-3.

Figure 30-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.

Additional Information

See the "Related Topics" section.

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 N² 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 Figure 30-4. (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 N², route lists and route patterns for the general case.

Figure 30-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 N² to N+1, and calling search spaces and partitions decrease from N to 1, as illustrated in Figure 30-5.

Figure 30-5 Provisioning TEHO With Local Route Groups

In Figure 30-5, 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.

Additional Information

See the "Related Topics" section.

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 Figure 30-6 for an illustration of this example.

Figure 30-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.

Additional Information

For more details about called party transformations, see the "Called Party Number Transformations Settings" section in the "Understanding Route Plans" of the Cisco Unified Communications Manager System Guide.

For details about the international + escape character, see the "Using the International Escape Character +" section in the "Understanding Route Plans" of the Cisco Unified Communications Manager System Guide.

Also, see the "Related Topics" section.

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

Additional Information

See the "Related Topics" section.

Interactions and Restrictions

The following sections describe the interactions and restrictions for local route groups:

•Interactions

•Restrictions

Additional Information

See the "Related Topics" section.

Interactions

The following sections describe how the local route group feature interacts with other Cisco Unified Communications Manager features and applications:

•Supported Devices

•Forwarding

•Other Supplementary Services

•Route Plan Report

•Cisco Unified Mobility

Additional Information

See the "Related Topics" section.

Supported Devices

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.

Other 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" section, 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

Before you configure local route groups, review the following restriction:

•Mixed Route Lists

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.

Additional Information

See the "Related Topics" section.

Installing and Activating Local Route Groups

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

Additional Information

See the "Related Topics" section.

Configuring Local Route Groups

This section contains information on the following topics:

•Setting the Local Route Group Service Parameters

---

Tip Before you configure local route groups, review the "Configuration Checklist for Local Route Groups" section.

---

Additional Information

See the "Related Topics" section.

Setting the Local Route Group Service Parameters

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

Additional Information

See the "Related Topics" section.

Related Topics

•Configuration Checklist for Local Route Groups

•Introducing Local Route Groups

•Local Route Group

•Binding a Provisioned Route Group to a Local Route Group During a Call

•Routing with Local Route Groups

•Called Party Transformations

•System Requirements for Local Route Groups

•Interactions and Restrictions

•Installing and Activating Local Route Groups

•Configuring Local Route Groups

•Setting the Local Route Group Service Parameters

•Route List Configuration, Cisco Unified Communications Manager Administration Guide

•Device Pool Configuration, Cisco Unified Communications Manager Administration Guide

•Gateway Configuration, Cisco Unified Communications Manager Administration Guide

•Trunk Configuration, Cisco Unified Communications Manager Administration Guide

•Called Party Transformation Pattern Configuration, Cisco Unified Communications Manager Administration Guide

•Calling Party Transformation Pattern Configuration, Cisco Unified Communications Manager Administration Guide

•Route Pattern Configuration, Cisco Unified Communications Manager Administration Guide

•Route Plan Report, Cisco Unified Communications Manager Administration Guide

•Route Group Configuration, Cisco Unified Communications Manager Administration Guide

•Calling Search Space Configuration, Cisco Unified Communications Manager Administration Guide

•Partition Configuration, Cisco Unified Communications Manager Administration Guide

•Understanding Cisco Unified Communications Manager Voice Gateways, Cisco Unified Communications Manager System Guide

•Understanding Route Plans, Cisco Unified Communications Manager System Guide

•Partitions and Calling Search Spaces, Cisco Unified Communications Manager System Guide

•System-Level Configuration Settings, Cisco Unified Communications Manager System Guide