The curse of Standard Local Route Group

One of the major bottlenecks related to scaling a dial plan in UCM releases prior to 7.x was overcoming the problem of site specific routing. Site specific routing is a term that ultimately means routing a call based on the location of the person making the call (originator/calling party).

Let’s take a look at an example Enterprise company in the US that has a single UCM cluster serving two locations, say, in San Jose and NYC. If a user sitting in San Jose dials a local number then the call should be routed out of the Enterprise gateway located in San Jose  since this is most likely the cheapest way to route the call. A different user in NYC with an IP Phone registered to the same UCM cluster as the user in San Jose hypothetically dials a local number in NYC and this call would most likely result in the call being sent out of the Enterprise gateway located in NYC.

How do we achieve this in UCM 3/4/5/6? Based on the assumption that a local call in both cities must be dialed using an access code of “9″ follow by 7 digits the first of which must be “2-9″,  the administrator would have to create two identical Route Patterns “9.[2-9]XXXXXX” each in separate partitions named for example “pt-sjc” and “pt-nyc”. Each Route Pattern would point to the appropriate gateway (via a Route List that contains a Route Group containing the appropriate gateway).  We end up with the following:

San Jose Local Call Routing:

9[2-9]XXXXXX/PT-SJC  > RL-SJC  > RG-SJC   > SJC-GW

NYC  Local Call Routing:

9[2-9]XXXXXX/PT-NYC > RL-NYC > RG-NYC > NYC-GW

San Jose Phones that are able to dial locally would be assigned a Calling Search Space (CSS) that contained PT-SJC. NYC Phones that are able to dial locally would be assigned a Calling Search Space (CSS) that contained PT-NYC.

I hope you see where I am going with this. The overhead to enable users at two sites to call locally is as follows:

• 2 Route Patterns
• 2 Partitions
• 2 Route Lists
• 2 Route Groups
• 2 Gateways

With two sites this overhead is not going to be of any great concern but let’s say the Enterprise has a remarkable year (they stopped selling oranges and started selling apples) and grew to 100 sites in North America. The overhead is 100 Route Patterns, 100 Partitions, 100 Route Lists, 100 Route Groups and 100 gateways. And this is only for local calls. Imagine what happens when you start allowing users to call other types of calls such as Emergency, LD and International numbers. Now this is most definitely a problem since the dial plan is rapidly becoming less manageable and you may have to make that call to TAC! Admittedly you do have the option to use the “@” wildcard with Route Filters which would allow for some improvement to the now out of control dial plan you have in year 2 of selling apples but this is does not solve the problem of making everything site specific- it only allows you to reduce the number of Route Patterns per site.

Enter the Standard Local Route Group (SLRG). The end of site specific routing is nigh. Sticking with our example of the local call in San Jose and NYC, SLRG allows for a single instance of a Route Pattern for local calls. This Route Pattern is provisioned in a single partition and points to a single Route List. We still need individual Route Groups and gateways so no savings there I’m afraid. Expand this to 100 sites and it doesn’t take a genius to figure out that the reduced configuration necessary to route a local call at each of the 100 sites is substantial- we end up with 1 Route Pattern, 1 Partition for local calls, 1 Route List, 100 Route Groups and 100 Gateways (assuming each of the 100 sites has a gateway with PSTN connectivity).

How does SLRG work? The phone (and other devices) all are assigned a Device Pool which is where group settings are provisioned. Things that all phones in a particular site will have in common such as time zone, default gateway for SRST, Codec and Call Admission Control characteristics, etc, etc. One of the settings new to UCM 7.x is Local Route Group. In our two site example we would create two Device Pools called DP-SJC and DP-NYC and the Local Route Group would be set to RG-SJC and RG-NYC in the two Device Pools respectivley. Remember a Route Group is just a list of gateways – in our case RG-SJC and RG-NYC would just contain the PSTN gateways in SJC and NYC respectively.

This Local Route Group setting is used when a matching Route Pattern points to a Route List which contains a virtual Route Group called “Standard Local Route Group” (as opposed to a user-created Route Group). When SLRG is being invoked, the originator’s Local Route Group setting contained in the originator’s Device Pool is retrieved and used for call processing. In effect the SLRG dynamically changes on a per call basis depending on the originating device (pool).

So we would end up with the following configuration that will allow users to call local numbers through their local gateway for all sites in North America:

North America Local Call Routing:

9[2-9]XXXXXX / PT-NANP-LOCAL > RL-LOCAL > SLRG

All devices in North America that are allowed to call locally would be assigned a CSS that contains PT-NANP-LOCAL. We would still need n Route Groups contained in n Device Pools and n gateways where n = number of sites. But in terms of Route Pattern, Route List and Partition creation we have a more scalable & manageable solution.

You may have noticed the title of this blog is called “The CURSE of SLRG”. If it’s a curse then why have I spent so much time making such a big deal out of it? Well the one major advantage of SLRG is not a factor in the CCIE Voice Lab.  And this is scalability. In the CCIE Voice Lab scalability cannot possibly be tested given time constraints. Instead you need flexibility and SLRG offers reduced flexibility.

SLRG is especially problematic if a mixture of gateway protocols is being used. With MGCP gateways all digit manipulation HAS to be performed within the UCM. If H323 gateways are being used, and especially remote site H323 gateways, you most likely want to push all digit manipulation for the called and calling number into the IOS. The latter point is especially important to cater for call routing if the branch site loses connectivity to the UCM and is operating in SRST. Users of phones registered to the SRST router will most likely retain their dialing habits and it is much better design to have one set of non-overlapping dial-peers within the remote site H323 gateway that are used to route calls when phones are registered to both UCM and the SRST router. So given a mixture of gateway protocols you are presented with a problem- you only have one Route Pattern and one Route List and you must cater for the MGCP gateway and hence will not be able to perform all digit manipulation within the IOS for the H323 gateway.

One possible solution is to use Calling and Called Party Transformation Patterns which are invoked at the gateway (so not RP/RLRG). And again this is great for real world but in the lab world (1) this might be considered overkill since the whole point of SLRG is to have reduced configuration and Called/Calling Party Transformation patterns will offer increased complexity in a two or three site deployment and (2) there are certain instances where Called/Calling Party Transformations are not flexible such as satisfying the requirement of modifying the Calling Number based on dialed number (10 digit ANI for local calls, 11 digit ANI for International calls as an example).

Another instance whereby SLRG offers no great benefit is if the endpoints registered to the cluster are in different dialing domains. The local Route Pattern in the NANP dialing domain (discussed earlier: 9+7 digits) is not something other dialing domains can use. So local calls in a different dialing domain will require a different Route Pattern (or potentially Translation Pattern) and again- the whole point of SLRG is reduced configuration and now you are back to square one!

So let’s try and summarize. SLRG is great in the real world. Not open for discussion. In the lab world it may cause problems since you may well have gateways of differing protocols and more than likely the lab will have more complexity than routing calls only through the local gateway. My personal stance would be to avoid SLRG unless one or more of these criteria are met:

(1) The lab instructs you to use it:-)

(2) If you have multiple gateways in the same dialing domain registered to the same UCM cluster that all use the same procotol. For example a San Jose and NYC gateway both using MGCP.

(3) AAR and CFUR- two very useful High Availability features that can be used when the network is congested and/or unavailable. In this instance calls should always be routed to the originating gateway and SLRG simplifies your configuration.

Good luck with your studies- and please let it be known that I have nothing against  SLRG- it’s not personal! It’s just that in 8 hours it doesn’t give me much.

Vik Malhi – CCIE#13890
Managing Partner / Instructor – IPexpert Inc

The curse of Standard Local Route Group, 3.8 out of 5 based on 6 ratings

Tags: ccie voice, slrg, standard local route group