Categories

CUC (6) CUCM (27) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Thursday, 10 May 2012

Call Manager using Standard Local Route Group, what's the deal?


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.

1 comment:

  1. I have 130 locations who all have speed dials to every other store. I had setup translation patterns to create these speed dials a long time ago and never looked at them again. In the middle of an upgrade to 9.1, I finally realized that any store that used that speed dial translation was sending their call over the internet to my corporate Call Manager and then out the PRI that is local here! I have been looking for a week for a way around having (130 X 130) different sets of these translation. I just knew there had to be a function for exactly this. Anyway, TAC couldn't help me and my "Tech Support" company wanted to charge an insane price just to look at it. Your site was the first one I found that solved my problem perfectly. Just wanted to say thank you!

    ReplyDelete