If you wanted to read more about the CFUR feature take a quick look at one of my earlier blogs on the feature (Using CFUR to Support SRST in CUCM). Building on the example introduced in the earlier blog, I wanted to showcase the power of Local Route Groups.
Local route groups (LRG) is a feature introduced in CUCM7x that allows administrators to customize Route List distribution logic to include a new “special” route group. The new route group is called the “Standard Local Route Group”. This special route group is used to tell the CUCM route processing engine to use a locally significant route group assigned to the calling device via the device pool.
Configuration Example
A visual may assist in understanding the functionality. Adding LRG configurations to your dial plan is rather simple. First, you create a route group as you normally would and assign the appropriate gateways. Second, you assign the route group to a device pool as shown in the folowing figure.
At this point we have assigned a Local Route Group to all devices that are members of the S1_User-Std_DP device pool. The next step is to configure a route list that can take advantage of this new configuration. For example:
We have a route list where we have assigned the special route group “Standard Local Route Group”. In this route list, we have also defined a regular route group in the second priority position to handle overflow and provide fault tolerance.
When we put this all together, a phone in the S1_User-Std_DP device pool that calls a route pattern using the CL_PSTN-Local-Global_RL will use the “Standard LRG” as the preferred call path. The Standard LRG points to the S1_PSTN-SIP_RG as defined in the device pool. The objective is to simplify the dial plan by minimizing the number of unique route patterns needed. If, for example, S2_User-Std_DP was configured to use S2_PSTN-PRI_RG as a Standard LRG then that route group is used first when the routing engine encounters CL_PSTN-Local-Global_RL.
Behavior of CFUR Without Local Route Groups
The following figure shows the typical call flow when using CFUR without local route groups.
We are experiencing a WAN outage and CFUR has been engaged for the phones in Site 1. Given the CSS we have assigned to the CFUR configuration, only one unique route pattern will be chosen to redirect the call. For the phone in the HQ site, call path [1] is used. There is no problem here as the path is optimal. However, the phone in Site 2 uses call path [2] and this isn’t optimal. Given that there is only one unique route pattern that can satisfy the redirect request, there is only one route group list that can be used. In our example, the HQ_GW_RG is our preferred route group. So, the Site 2 phone must establish a media path across the WAN to the HQ site and then get routed to the PSTN.
Prior to the Local Route Group feature this sub-optimal scenario was just something you had to deal with.
Behavior of CFUR With Local Route Groups
With LRG we now have the ability to optimize call path [2]. This optimization is demonstrated in the following figure.
While the call path used by the HQ site phone is the same, how we got there is different. Again, we are using CFUR on the phone in Site 1. We are still using the HQ_PSTN_CSS calling search space and the HQ_PSTN_RL route list. However, we now have a different route group configured: “Standard Local Route Group”.
For call path [1], when the call is redirected the CUCM routing engine will see “Standard Local Route Group” and then check the device pool assigned to the HQ phone. In the device pool we find that CUCM is instructed to substitute HQ_GW_RG for Standard LRG and then route the call as normal. As noted, the call path is the same as the previous example. It is already optimized.
Call path [2] demonstrates the optimization benefit of Standard LRG. Again, we are using the same CFUR CSS and the same route list. The phone in Site 2 has a different device pool assignment and, therefore, can have a different LRG assigned. In our example, Site 2 uses the S2_GW_RG as the standard LRG and this route group uses the voice gateway local to Site 2. In contrast to example 1, which required the media stream to flow through the WAN, call path[2] with LRG will keep the media stream on the local network and the call flow is now optimized.
This example is but one demonstration of how Local Route Groups can improve the capabilities of your dial plan architecture as well as give you the ability to do a little clean up and consolidation. Another good example would be remote site 911 dialing. You can now have one pattern using route list configured with Standard LRG instead of having a 1:1 ratio of 911 patterns to remote offices. Pretty cool stuff.
With CUCM 7x, you can extend the positive impact of LRG even further by coupling it with the “globalization routing” concept. But I think that is a topic for another day.
There is a issue that LRG cannot be deployed.
When an IP phone with 2 extensions, line 1 is HQ extension and Line 2 is Remote site extension, before using LGR, we can use Line 1 to dial out via HQ gateway, line 2 to dial out via remote gateway (over WAN), however, when LGR is used, Line 1 and line 2 will always go out via HQ gateway (because LGR based on device pool and one phone can belong to 1 DP at same time), Would cisco improve this based on CSS?
TY,
At the most basic level, you are correct – LRG does not easily fit into the model you describe. From a design perspective, you need to determine what fits your business and technical requirements. You also need to determine if the configuration you define is a standard rule or an exception to a rule. This will help you determine viable workarounds.
I have seen this line configuration before. Not so much in WAN deployments, but in MAN deployments where there is a centralized call processing solution but a distributed gateway solution.
Of course, my design preference/recommendation is that the device level dictates call path and not the line level. The only accommodations I would make on the line level is supporting an abbreviated dialing solution for a multi-tenant environment (i.e. keeping calls On Net). Outside of that, I don’t like sending calls over the want to seize a remote PSTN trunk based on the line I am using. Traffic engineering considerations come into play. As does 911 calling. So, if someone accidentally picks up the remote site extension and dials 911, they will route out a remote gateway and reach a remote PSAP? That is not a good situation.
That being said, I have found that LRG has a very specific focus. Which means that when you have requirements outside of this core use you need to use other tools. There is nothing saying you can’t mix the previous route group approach with local route groups. I do it all of the time. Simply because LRG isn’t the cat’s meow for all tasks.
Coming back to your issue. If you keep LRG as your standard model, then you need to engineer a one-off solution that fits your overall design. Make sure you think all variations through before you start clicking away on the CCMAdmin interface.
HTH.
-Bill