In network engineering I have learned that the biggest lie I tell myself is that “I do not need to write this down.” That being said, when you are in the heat of troubleshooting a production issue I really try to design my systems so that I can tell what the heck something does by a label or good name. This does not replace the need for other documentation, but it does help when you are in the heat of troubleshooting a system problem. As I started supporting Unified Communications applications, I discovered there are lots of opportunities to really create a mess when you are configuring things if you do not keep supportability in mind. I want to share with you some tips that I have found helpful in naming objects specifically in Cisco Unified Communications Manager; however, similar concepts can be used for other network components such as Access Control Lists on traditional network equipment too.
When you are starting with a fresh Cisco Unified Communications Manager install, you have a blank slate. This is both good and bad. Good in that you have a lot of flexibility in the system to configure things, but bad because if you don’t put some thought into naming it can get confusing quickly. Spending some time up-front will save you some headaches down the road. Even if you don’t have a fresh Cisco Unified Communications Manager installation, you can start cleaning things up as you provision new services and go back and adapt what is in the other systems when you have time to do so.
Some of the common things you will configure in Cisco Unified Communications Manager will be: Partitions, Calling Search Spaces, Route Groups, Route Lists, Route Patterns, SIP Trunks, Device Pools, etc. First let’s get started with some basic definitions of what some of common objects are. I will also share some examples of how I like to name things to keep them easily sorted so objects of similar function are grouped together in a long list. These are just examples, and your naming convention will have to be something that works for you, your team and your specific environment.
Partitions – Partitions facilitate call routing into various objects by separating objects into logical subsets or groups. This sounds a little confusing on the surface, but I keep straight in my mind by thinking Partitions get me into the various Cisco Unified Communications Manager objects. I like to begin all of my Partitions with “P-“ and group similar partitions together further by using similar names. Here are some examples:
- P-ONCLUSTER – partition for most Directory Numbers that don’t need to be isolated for contact center routing
- P-ONCLUSTER-UCCE – partition for Contact Center Directory Numbers that need to be routed first to Unified Contact Center Enterprise before routing to the IP Phone
- P-PLAR-HQ-SECURITY – partition for a Private Line Automatic Ringdown to headquarters security office
- P-PLAR-HQ-RECEPTION – partition for a Private Line Automatic Ringdown to headquarters reception desk
- P-PSTN-HQ-LD – partition for headquarters long distance call routing objects
- P-PSTN-HQ-LOCAL – partition for headquarters local call routing objects
Calling Search Spaces – A calling Search Space is an ordered list of partitions that are typically assigned to various objects. Calling Search Spaces determine the partitions that objects/devices search when they are attempting to complete a call. Calling Search Spaces are used a lot in Cisco Unified Communications Manager so this is where you can get yourself into trouble quickly. Similar to partitions, I like to group similar Calling Search Spaces together by make my names sort to keep them grouped together when you are scrolling in a long list of calling search spaces in the administration graphical user interface. Here are some examples:
- CSS-DEVICE-HQ – Assigned at phone level for headquarters location call routing
- CCS-DEVICE-NY – Assigned at phone level for New York location call routing
- CSS-GATEWAYS-PSTN-INBOUND-HQ – Assigned to gateways for inbound calls in the headquarters location
- CSS-GATEWAYS-PSTN-INBOUND-NY – Assigned to gateways for inbound calls in the New York location
- CSS-LINE-INTL – Assigned at DN level for international calling permissions
- CSS-LINE-LD – Assigned at DN level for long distance calling permissions
- CSS-PLAR-RECEPTION-HQ – Assigned at phone level for headquarters location reception Private Line Automatic Ringdown
- CSS-PLAR-RECEPTION-NY – Assigned at phone level for New York location reception Private Line Automatic Ringdown
Route Groups – A route group allows you to designate the order in which gateways and trunks are selected. It allows you to prioritize a list of gateways and ports for outgoing object/device selection.
- RG-PSTN-HQ – Route Group for headquarters location Public Switched Telephone Network trunks
- RG-PSTN-NY – Route Group for New York location Public Switched Telephone Network trunks
Route Lists – A route list associates a set of route groups in a specified order. A route list is referenced with one or more route patterns and determines the order in which those route groups are accessed.
- RL-PSTN-HQ – Route list for headquarters location Public Switched Telephone Network trunks
- RL-PSTN-NY – Route List for New York location Public Switched Telephone Network trunks
SIP Trunks – A Session Initiation Protocol trunk is used to connect Cisco Unified Communications Manager to other devices or applications. The most common applications that use Cisco Unified Communications Manager SIP trunks are for voice and video calling as well as instant messaging presence awareness. Some examples of types of applications that use SIP trunks are: call recording applications, E911 call routing applications, voicemail systems, etc.
- SIP-CUBE-HQ – SIP trunk for Cisco Unified Border Element at headquarters location
- SIP-CUBE-NY – SIP trunk for Cisco Unified Border Element at New York location
- SIP-VOICERECORDING-HQ – SIP trunk for voice recording application at headquarters location
- SIP-VOICERECORDING-NY – SIP trunk for voice recording application at New York location
Device Pools – Device pools define sets of common characteristics for devices. Device pools reference lots of other objects including Cisco Unified Communications Manager Groups, Date/time Groups, SRST References, etc. Similar naming conventions can be used for these object types as well.
- DP-ADMIN-HQ – Device Pool for admin phones at headquarters location
- DP-ADMIN-NY – Device Pool for admin phones at New York location
- DP-UCCE-HQ – Device Pool for Unified Contact Center Enterprise phones at headquarters location
- DP-UCCE-NY – Device Pool for Unified Contact Center Enterprise phones at New York location
Hopefully you could see in my examples, I try to develop a naming standard that makes since for the environment by naming items so they group together neatly in long lists of objects. In the case of our production Calling Search Space list, I have over 100 items configured. When I am troubleshooting or configuring something new, I would prefer not spend my valuable time scrolling up and down in that list finding all the things I need. Cisco’s own Solution Reference Network Designs, show naming examples like: “Phone_css” and “Internal_css”. That works fine for a small lab setup, but you can quickly tell this naming convention isn’t going to scale well in a large list of Calling Search Spaces.
I would encourage you to spend a little time up-front to save yourself a lot of headaches down the road. If your naming standard needs to change down the road, that is okay too. You can rename most things pretty easily in Cisco Unified Communications Manager. Sometimes is does require a reset on the objects, regardless, the system can adapt and change as your system grows.
Other advice for configuring Cisco Unified Communications Manager? Try has hard as possible to not tell yourself, “I don’t need to write this down.”
Nice post, Michael.
This naming system has pros and cons. And you were absolutelly right when said that everybody should choose their own name convention which is most suitable for the company. For example, in the wide geographically distributed systems the area code or prefix might be the best choice so that all configuration elements in web interface are listed together. While in the small companies administrators prefer to give “object-oriented” names such as “internal_css”, “boss_partition”, etc.
That’s why Cisco and other vendors don’t have any “strongly recommended” naming convention and leave this choice for the local administrators.
Great post and topic. Naming is important. The convention used should be able to be scaled to support additional locations, functions, roles, departments. If this information is not an accessible policy you’re at the mercy of getting a name based on how an administrator feels at that moment. Even small business should have a naming convention that assumes massive growth.
Excellent post Michael, and something too often missed by companies and installing engineers. Too often I have seen vague names that dont support the purpose of the PT or CSS.
One thing I would also like to point out is that you also need to beware of Partition naming limitations. This can catch you out in very large deployments.
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_01110.html#CUCM_RF_PF695B87_00
I took the decsision to rename our partitions by reducing the characters where possible to support growth.