Thought I would do a post on using Standard Local Route Group (SLRG) and what thebenefits are, and YES you should definitely give a hoot (ever since CUCM 7.x really).
Why? Well lets assume the following number plan (not using globalization), my favorite; the Australian Number plan. If you were to cover that off using a national number plan, that could easily mean you would have to use 10-15 route patterns (including patterns for premium calls, directory assistance, operator services, dial before you dig 1100 etc. etc.). In a multi site deployment, i.e. each site has its own local PSTN gateway (could be TDM, could be a SIP Trunk to a provider), in order to have a site use its own local gateway,(site specific call routing) you would have to add 10x15 is 150 route patterns. Because each route pattern would need a pattern with its own site specific a Route List that would point to its own local gateway. When the Standard Local Route Group is used, this is brought back to only 15 route patterns. And laziness, for lack of a better word, is good.
How does it work? The trick is that by using SLRG, a phone's device pool will dictate which Gateway will be used, contrary to the site specific Route Pattern's Route Group. So if a phone dials a number that is matched by a pattern that uses SLRG, it invokes the Local Route Group that is defined in the device pool of the phone that originates the call. That principle works really well based on the assumption that all phones at a certain site, can be configured with the same general properties, such as SRST reference point, Date/time group. CAC and AAR properties through a device pool, which is pretty much the case for most deployments. But even if you would use multiple device pools at a certain location, as long as the LRG is the same in all of them, they would still point to the same local gateway.
How to configure the bastard?
(Screen shots below are from Unified Call Manager 8.6.1)
Choose the "standard Local Route Group" as the route list member. This route group is pre-populated, during install and cannot be deleted or removed
|Local Route List Configuration, using standard local Route Group|
I called this route List RL_LOCAL, as you can see, and have applied it to a globalized pattern +! (more posts to follow on this subject)
|Route pattern configuration using Local Route List|
Apply the local Route List to the device pool, this will use my gateway(s) in Melbourne for any call originating from a phone in my Melbourne device pool.
|Local Route Group configuration in the device pool|
What's the catch? there aren't any,....hang on there are. For instance in deployments that use MGCP, using SLRG's dont work too well, this is because the would potential digit manipulation is backhauled to the CUCM and we have just established the fact that that with the one route pattern fits all approach we have stepped away from this concept. Summarized, by using SLRG you will lose some flexibility in terms of digit manipulation, i.e. you will loose the ability to perform site specific manipulation on Route patterns and Route Lists, because they are "catch all". One possible solution is to use Calling and Called Party Transformation Patterns which are invoked at the gateway (so not RP, RL and/or RG). Also, if you are happy doing all your digit manipulation on IOS level (which most likely you will need to do anyway to cater for SRTST), then you will not loose any functionality.
Another thing that I need to mention is Tail end Hop off; you cannot use SRLG if you are planning to deploy this. This simply because the Route patterns will force a call to a gateway that can provide least cost call routing, which goes against the concept of having the call originating device dictate the gateway.
Please comment on this post if you want to discuss this topic or if you find any inconsistencies in it. Or simply, because you think my drawing skills are shit.