Some Cisco UC Basics, part Deux

Cisco's call control product is UC Manager, which used to be named CallManager, and gets referred to as Communications Manager or CUCM.  It's designed to be scalable, potentially up to 10,000 endpoints registered per node.  The per-node scalability is determined by the VMWare OVA template that gets applied in the initial build-out of the system.  Systems Integrators will choose the correct OVA by evaluating the current number of endpoints in the environment plus a target growth number, which normally is provided by the customer.  The reason not every Systems Integrator goes right to the 10,000 user OVA is that the system specifications for those virtual machines is weighted heavier, therefore available system resources on the physical host are reduced,  which reduces the overall capacity of the physical host to hold other virtual machines.

UC Manager nodes can be clustered together, and that involves a Cisco proprietary protocol that passes call and endpoint state between nodes within the cluster.  This proprietary protocol requires that every node maintain a connection to every other node, so the connections are fully-meshed.  This impacts bandwidth required between nodes in the cluster, as a single connection requires up to 1.5MB of bandwidth.  This is a big deal if you are planning to cluster nodes over the WAN, and have limited bandwidth to work with.  This protocol allows for the entire cluster to act as one big registrar for endpoints.  Cisco allows for up to 8 call processing nodes in a cluster, and they cap the number of phones per cluster at 40,000. 

In SIP terms, UC Manager is a B2BUA, however media never flows through, it's always between endpoints.  This isn't even an configuration option to change this.  This fact gives a little bit more predictability to the scalability considerations of the system.  Nowadays, SIP is definitely the protocol of choice for CallManager, both line-side to endpoints and trunk side to PSTN gateways, although the protocol used to the gateway can vary depending on what Cisco voice engineer you talk to.

The gateway is almost always a Cisco router.  Voice functionality is built into Cisco's networking OS (IOS), and is enabled by a "UC" license.  The gateway runs one of 4 possible protocols: SCCP (Skinny), MGCP, H.323, or SIP.  The protocol used is usually determined by what the customer is connecting to the gateway.  Analog lines, for instance, usually work better if SCCP or MGCP is used. PRI's are going to entail usage of either MGCP, H.323, or SIP.  If the customer is setting up a SIP trunk to a telco, SIP would be the protocol used from the gateway to CUCM.  MGCP relies on CallManager for call control and dial-plan decisions.  H.323 and SIP are effectively peer-to-peer protocols, meaning there are separate dial-plans and call routing decisions made on both CallManager and the gateway.  Another set of functions that the gateway can provide is transcoding, ad-hoc conferencing, and Media Termination Point (for media relaying and DTMF termination) services.  These services register to CUCM using SCCP, and can easily be co-located with the other protocols.

In the first part of this series, I mentioned that Cisco had chosen IBM Informix for the database component.  The way that CallManager passes configuration data between nodes is through a database Publisher/Subscriber model.  There are a few challenges to this approach in the CallManager space.  The first node installed becomes the Publisher server.  This role is locked in to the first installed node, and cannot be changed later without more or less backing up the Publisher, re-installing, and restoring the backup.  So if you find yourself with a downed Publisher and no backup, you'll have a headache in front of you, because the environment will need to be rebuilt.  The Subscriber nodes will continue functioning, however no configuration changes will be able to be made to the servers without that Publisher.  Cisco has not provided the capability to promote a Subscriber server to a Publisher.  Also, for sometimes unknown reasons (and quite a few known ones), database replication will break.  There's a list of CLI commands to go through when this happens, and that resolves the problem 80% of the time, and the remaining 20% of the time you will be on the phone with Cisco's Technical Assistance Center (TAC).

Stay tuned for part 3, where I'll talk about some of the other Cisco UC applications (client and server).

UC Keep It Simple Stupid #2 - Naming Convention Phooey

Ever noticed that every configuration example from Cisco for UC Manager names elements with the element type abbreviated along with a "-" or "_" before or after the abbreviation.  For example, a device pool would be named SiteA_DP, along with Site A's CSS being SiteA_CSS, and maybe some Internal_PT and PSTN_PT to go along with it.  This annoys me to no end, ultimately because it is a "zero thought process required" approach, and one that's taken all too often.  Think about it.  There's no reason to include a _CSS or _PT on the end of these configuration elements, because you can't accidentally choose a CSS in a partition drop down menu!  I have a (semi-)short list of recommendations I follow when I design a UC Manager naming convention:

1. Don't include the type of the thing you are naming in its name (did you think this WOULDN'T be #1?)

2. Establish the goals of your naming convention ahead of time, then tweak the names to conform to your goals. 

3. Think about scalability.  If your CUCM is going to be scaling to a large number of sites, opt for a standard site naming convention that won't require you to re-do things a year or two down the road.  

Your first location in Georgia could be GA1.  This works until you have 10 sites in GA, then the formatting gets a bit hokey.  What happens when you need to add a Germany site?  You can see where this is going.  

4. Don't overcomplicate the naming.  At the same time, if you know for sure that your organization will never scale outside of 10 sites in GA, just call the sites by whatever common name you usually refer to them.  Don't bloat your naming and make things confusing if you don't have to.  While this may seem to conflict with #4, remember that it's your job we're trying to make easier here, and the job of the person that will replace you (because you're so awesome at this naming convention business, you got a promotion).

5. Be descriptive for the function of the element, and don't be afraid to include a space or two or three in the name.  Seriously, it won't hurt anything.  (There's a caveat for this in complex dial-plans, where there is a 512 character limit of the partitions in your individual CSS's.  See here: http://bit.ly/isXeDV) 

6. Try to match up the naming of the functions to commonly terminology used elsewhere in the platform.   I've been in a habit lately of calling my phones partition "All Directory Numbers".  I've seen this partition named anything from Internal_PT to Extensions_PT to Cluster_PT, none of which logically match up to what type of numbers are put in the partition.  DIRECTORY NUMBERS.  Make things fool proof and you might just save yourself from...yourself. 

7. For site specific elements, decide on how you want those elements listed, either by function or by site.  I generally name my individual site CSS for phones "Site Name - Phones". Typically though I will also have a CSS for gateways named similarly "Site Name - Gateways".  In the drop down this would look like:

SiteA - Gateways

SiteA - Phones

SiteB - Gateways

SiteB - Phones

SiteC - Gateways

SiteC - Phones

You might prefer to have all the CSS's grouped by function first, then site name, so my individual site CSS would become "Phones - Site Name".  

Gateways - SiteA

Gateways - SiteB

Gateways - SiteC

Phones - SiteA

Phones - SiteB

Phones - SiteC

This ties back to #2.

8. Don't be afraid of using numbers or "_" in front of names in order to influence ordering the lists.  If you want a particular group of partitions to always be last, include a "_" in front of the name.  If you want something to always be at the top, number your partitions starting with 0. 

Naming conventions are NOT an exact science, and are very subjective.  That's why it's important to establish your own naming guidelines before you set out to design or redesign your own infrastructure.  Now I'm going to go rename this blog UnifiedConfusion_BLOG.

Great read over at networkingnerd.net entitled "9.@ Must Die!" Yes! Agreed!

Tom Hollingsworth wrote an excellent post about ditching the 9.@ route pattern and the subsequent route filters.  Love it.  Cisco needs to remove this from the SRND and let it quietly fade from view. http://networkingnerd.net/2011/05/26/9-must-die/