One of the concepts that many junior voice engineers struggle with is the class of control features of Partitions and Calling Search Spaces. I remember feeling like I was banging my head against a wall repeatedly until I hit that Ah-hah moment and it all made sense.
Now there are many great explanations out there on the inter webs that are all technically correct and great. Some use the Lock + Key analogy like the CIPT1 Study guide and some use a White Pages/Directory Analogy. In my opinion these can leave people without a whole lot of voice experience more confused than when they started.
Purpose – What are Partitions and Calling Search Spaces used for anyway?
In my opinion Partitions and Calling Search Spaces are primarily used as a way to find “things” in the phone system. They are used so endpoints (Phones, Gateways, Trunks) can dial resources (Directory Numbers, On-net Route Patterns, Off-net Route Patterns, Translation Patterns). From an end-users perspective these resources are generally represented by a number. Because you can use these Dial Plan constructs to limit what resources an endpoint can find, it allows you the ability to implement Class of Service.
Yeah, Ok. But you still haven’t told me what Partitions and Calling Search Spaces do!
Hold your horses. This is the part you’ve all been waiting for….< Insert Drum Roll > Here it is:
- Partitions contain “things”
- Calling Search Spaces find “things”
That’s it. I really believe this is the simplest way to think of how these two constructs work and behave.
So we know that partitions can contain “things” but what exactly can they contain? A partition will only contain one or more of the following things:
- Directory Numbers – These Directory Numbers represent other numbers in the Phone System that can be associated to Devices.
- Route Patterns – Route Patterns represent off-net and on-net destinations and control how a call is routed to a destination. Route Patterns use Route Lists and Route Groups to send calls over a trunk or a gateway.
- Translation Patterns – I consider Translations Patterns an intermediate step to either matching a Directory Number or a Route Pattern. They are used to Transform the Calling or Called Party Information before using a Calling Search Space to find a suitable match. It is also worth noting that a Translation Patten can also be set to Block instead of route which can be useful when using the Line/Device Approach for implementing Class of Service
- Transformation Patterns – Transformation Patterns are similar to Translation Patterns except they are not part of the CUCM’s routing construct. They are used for modifying Calling or Called Party Information for purposes of presentation but do not affect call routing. When you are using Transformation Patterns you should use dedicated Partitions and Calling Search Spaces for this function.
Calling Search Spaces
So if partitions contain “things” and Calling Search Spaces find “things”, what do they look in too find them? Well they look in partitions of course.
The following constructs use Calling Search Spaces to find things:
- Devices – Phones use a CSS to find available patterns. This is generally referred to as the Device Calling Search Space
- Directory Numbers – Directory Numbers also use a CSS to find available patterns. This is referred to as the Line Calling Search Space.
- Translation Patterns
This list was by no means exhaustive and there is a vast number of features that require Calling Search Spaces to be defined to control access to DN’s/Patterns for that feature. Things like Time of Day Routing, Presence, Call Forward Settings etc
When a Calling Search Space is looking through a series of ordered partitions it doesn’t work like an ACL in Cisco IOS that searches sequentially through the available partitions top-down until it finds a suitable match. No, It processes all listed partitions and matches on the best or longest match. The only time in which the order of the partitions matter is when you have equally specific patterns, in which the pattern in the partition closer to the top of the CSS list will win as a tie-breaker.
OK – So I think I get it, but I’ve noticed my Phone and my Directory Number both have a CSS. What’s up with that?
Well CUCM is flexible in that you could choose to set a CSS on just one of these elements and leave the other blank. When you have both a Device and a Line CSS the CUCM combines the two into a single CSS with Line CSS above the Device CSS.
There is a good reason to use both. In order to effectively use features like extension mobility but enforce local dialling habits at remote offices it is recommended to set the Device CSS as too allow full access to the Dial Plan and then use the Line CSS to restrict unauthorised patterns from being dialled. The Partitions in your Line CSS should contain Translation Patterns that are set to block the restricted patterns and also have the “Urgent Priority” flag checked (It is on by default).
If you would like more information about the Line/Device approach please check the SRND.