Local Route Groups were introduced in CUCM 7 as a cleaner way to configure PSTN routing for multiple sites. Prior to Local Route Groups, the only way to route calls out a local gateway was to configure a partition for each site, and configure the various PSTN patterns in each one. With local route groups, you can tie a route group to a device pool, and then send route patterns to a route list that includes the “Standard Local Route Group.” Calls matching that pattern will then use the local route group configured for their device pool.

Configuration  example after the cut.

For our example, we will look at a site with 3 locations: Milwaukee (414 Area Code,) New York (516 Area Code,) and Los Angeles (213 Area Code.) Each site has a local PRI which should be used for all outbound calls.

In a classic setup, there would be a MKE PSTN, NY PSTN, and LA PSTN partition that each contain all the PSTN route patterns. Usually you have 5-6 patterns each, something like 9.[2-9]XXXXXX, 9.1[2-9]XX[2-9]XXXXXX, 9.@ (Toll Free,) 9.@ (International,) 911 and/or 9.911. With a large number of sites, this can grow quite quickly.

With local route groups, you can create a single set of route patterns, and they will automatically route to the nearest gateway based on device pool. Since device pool can be set via device mobility, phones can be moved between sites, and always use the local gateway. In this example, sites will only use the local PRI for outbound calling, so emergency calling can follow the local route group.

Building from the ground up, we need to configure the gateways, MKE_PSTN_GW, NY_PSTN_GW, and LA_PSTN_GW. We then configure a route group for each: MKE_PSTN_RG, NY_PSTN_RG, and LA_PSTN_RG, pointing to the PRI interface on each gateway.

Once we have the route groups built, we can create the device pools, MKE_PHONES_DP, NY_PHONES_DP, and LA_PHONES_DP, and add the appropriate route groups to them.

We also need a route list, which we will call USE_LOCAL_RL, which only contains “Standard Local Route Group.”

To provide for emergency routing and any other site-specific dialing, we are going to create site partitions and calling search spaces. They will be MKE_LOCAL_PT, NY_LOCAL_PT, and LA_LOCAL_PT, and each contain 911 and 9.911 patterns pointing to a route list containing only the local PRI. If you will not be doing any backup routing you do not need to do this, since the emergency patterns will exit the local gateway.

We also need a partition for internal DNs (INTERNAL_DN_PT) and the global PSTN routes (GLOBAL_ROUTES_PT).

The Milwaukee calling search space will be as follows:

The others are built the same way with the proper local partitions.

Now we can build the route patterns as follows, each pointing to USE_LOCAL_RL:

• 9.[2-9]XXXXXX
• 9.1[2-9]XX[2-9]XXXXXX
• 9.@ (route filter: Toll Free)
• 9.@ (route filter: International)

When CUCM matched a dialed number to one of these patters, it will look at the device pool of the calling device, and find the local route group configured there, then route the call to that route group.

Configuring TEHO with local route groups

TEHO, or Tail End Hop Off, allows calls to be routed to the gateway nearest the destination, rather than the gateway neared the phone. Depending on the cost of long distance vs. the cost of WAN bandwidth, this can save and enterprise money, due to the current long distance rates, it is usually not as compelling a reason as it was previously.

With a classic configuration, you need a route pattern in each site partition, so that users can fail over to the local circuit if the “tail end” route is not available. With local route groups, you can create a single route pattern for each TEHO destination, and route lists that contain the TEHO exit point, and “Standard Local Route Group.” So to add the two local area codes for Milwaukee, 414 & 262, you would need to create a route list, say “MKE_TEHO_RL” that contains MKE_PSTN_RG, and “Standard Local Route Group,” then route patterns 9.1414[2-9]XXXXXX and 9.1262[2-9]XXXXXX that point to the MKE_TEHO_RL.

Doing centralized outbound calling, such as over a SIP trunk to and Internet Telephony Service Provider (ITSP) would be the same setup, only you would be pointing your long distance patterns to a route list associated with the SIP trunk and the Standard Local Route Group.

Looking for more CUCM tips and tricks? Click Here to read more of my CUCM posts.