Sunday, May 29, 2011

UC Keep It Simple Stupid #1 - Dial-plan, smial-plan


Overcomplicating is a very common issue amongst engineers, in just about every discipline.  Unified Communications is no exception, with Cisco leading the vendor pack (wolfpack?) in the way of confusing their customers.  Yes, I know that complexity breeds flexibility, but for my customers it equals an insanely steep learning curve that can be difficult to surmount.  The first of my "Keep it Simple Stupid" posts will address one of the more complex elements of Cisco's Unified Communications Manager, the dial-plan. 

There's a very common occurrence whenever I start talking about partitions and calling search spaces with customers; eyes start to glaze over, beads of sweat start swelling up on foreheads, and the inevitable question: "What training classes are available for this??"  "Relax," I tell them, "we'll go over all this before I leave."  I spend a few hours slowly beating them to death with my powerpoint presentation on CUCM administration, and normally the situation doesn't get any better.  Nine times out of ten, their biggest lack of understanding is around the use of partitions and calling search spaces.

A long time ago, in elder versions of CUCM (read CallManager), You created a single set of route patterns, and single set of partitions, and single set of calling search spaces for each site.  This was easy to understand (relatively speaking), but it didn't scale well.  

Then Cisco started recommending the Line/Device calling search space model, which did greatly decrease the number of route patterns and partitions in use.  Since we decreased the number of things to configure, this made the dial-plan easier to understand, right?  Not so much.  The Line/Device method (to put it simply) uses calling search space concatenation to merge two layers of partitions together.  The top layer consists of the gates that a call must pass through in order to get to the bottom layer of partitions, which actually contain route patterns that will connect your call.  If the top layer contains a match for a particular type of call that isn't allowed, say an international pattern, the call is blocked.  Make sense?  Right.   Below is a visual representation of this concept.  In this particular example, the only allowed calls would be local, because international and long distance patterns are targeted for being blocked.



I'm writing to recommend a different approach, one that captures some of the glory of the ol' easily understood days.  There's a really handy feature that was introduced in 7.x called Local Route Group.  This feature allows you to dynamically assign a route group (gateway) to a shared route pattern based on whatever phone is dialing the pattern.  The Local Route Group is configured in the Device Pool of the phone.  If I have a gateway at my New York location, and the phones in the New York location dial the standard long distance route pattern (9.1[2-9]XX[2-9]XXXXXX is what I use), the logic in the Local Route Group will evaluate the phones' device pool setting for route group and choose the first gateway in that list.  Magic?  Almost.

So how do you get there from here?  First, create a new route list, called something like Standard Local Route List.  This list will have the same settings as your normal route list, but it's route group will be a special one in the drop down menu called Standard Local Route Group.  That's the secret sauce that marries any given route pattern to the phone's configured gateway.  The route pattern will point to whatever gateway (route group) is assigned to the device pool of the phone that dialed the pattern, thus leaving you with a common set of route patterns that will scale to all devices.  

Back to partitions and calling search spaces.  We will still use the concatenation of the line and device calling search spaces, but no more of this silly blocking business.  Your device calling search space will have all your internal partitions, plus something to stick your 911 route pattern in (we don't want to toss that one up to user error).  Create one calling search space per type of class of service.  I usually have International, Long Distance, and Local.  Your International CSS will include an international partition, a long distance partition, and a local partition.  Your Long Distance CSS will have a long distance partition and a local partition.  I'm sure you can see where I'm going with this.  These partitions should contain the route patterns for each respective type of number, all tied to the Standard Local Route List that will allow that dynamic allocation of gateway to dialing phone.  Here's what this might look like:


No more reverse logic, and fewer route patterns and partitions to boot.  This will NOT APPLY TO ALL SITUATIONS.  Your mileage may vary, and I definitely recommend the use of a lab to test this configuration out before you start making changes willy-nilly. Happy configuring!

2 comments:

Student said...

Unified Confusion - is it real ?

I am a beginner average one in VoIP world. I am sorry to say this ( and i might sound a fool here but i dont care) :
Why many topics (especially in IPCC world) like CSS, partition, route pattern, Device pool, Location bla bla in CUCM/IPCC/IPT world are all so confusing?

Even more confusing it becomes when you talk about CUCM with CVPz, ICMz and their components E.T.C

If you try to search web on these there is tones of paraz in out there but 99% of the info on web DOES NOT explain how all these FIT in the bigger picture. All they simply do is tell you how configure it, how to install it and all that.

i.e they only tell you how to do it but NOT why we are doing it ?

This is so confusing and frustrating at times. It even looks deliberate, sorry to say.

Unknown said...

I have to apologize to you, because 7 months after you posted this, I never once got an email notification that you had left a comment. This is a great point, and I will attempt to address that in some future posts. There are Cisco Press resources available to learn these things, but not everyone has access to this information.