Cisco – the NO PAYLOAD ENCRYPTION version of the IOS software

In order of preference/priority, our company tends to upgrade based on these factors:

• Vulnerabilities, vulnerabilities, vulnerabilities!
• Bugs
• Attaining new features not currently available-- new cards/modules have a "first supported in" IOS version which could be higher than what you have running
• Migrating away from retired release trains
• Matching versions on more recently deployed and similar hardware

A device that is very critical to the infrastructure may not be as aggressively upgraded as one that is less critical. Consideration is given to the role of the device, the redundancy surrounding it, and the impact of the upgrade itself by the downtime incurred or by the possibility of having config feature behavior changes or different defaults when going between major versions. This is the necessity question that also touches on soft costs such as the time and resources to accomplish the upgrades measured against the weight given to each of the factors such as vulnerabilities.

Be sure to subscribe to multiple vulnerability announcement sites such as Cisco PSIRT (Product Security Incident Response Team) and the US Cert (Computer Emergency Readiness Team).

A downgrade might be in order if:

• Organization has a policy to only run tested/QA'd versions and new equipment came with a more recent release.
• Org has a policy against running anything other than GD.

• Use Cisco's Output Interpreter of "show version" to look for obvious issues/vulnerabities/bugs.
• Look for GD (General Deployment) releases and avoid DF (Deferred).
• Use ED (Early Deployment) only when it contains must-have features not available elsewhere.
• Avoid LD (Limited Deployment) when possible and use GD instead.

There are certainly arguments for going to an ED or LD version, but the desire, of course, is to get to the most stable version that meets requirements. Use Cisco's Feature Navigator to help identify potentially different feature-sets (assuming you're licensed to use them).

Cisco does a fantastic job obscuring this information for some reason. To answer your specific questions:

1. System Version 7.1.5.34900-7 is actually CUCM Version 7.1(5b)SU4. You'll need to download System Version 7.1.5.35901-1 or higher, to get the OS and Application fixes that are found in CUCM Version 7.1(5b)SU6a.
2. I wouldn't go so far as to say that there is always a 1-to-1 relationship between the two formats (CUCM Version vs System Version). However, in my experience, when Cisco releases a new System Version, they also increment the CUCM version number.
3. In older versions of CUCM, there was a much greater disconnect between "OS Fixes" and "CUCM Fixes", which would give you the disparity that Michael Luo describes in the page you linked. However in recent times (post version 7.1 days), all of the recommendations that I have received from Cisco TAC, seem to indicate that the higher the number, the better, period.

The only exceptions that I have encountered, are unreleased "Engineering Special" versions; special releases that are usually only distributed by TAC to fix a very specific and uncommon bug. In the event that you are on an "Unreleased ES" version, you should contact TAC for upgrade support anyway, as there may be undocumented bugs related to upgrading from that version to a normal, mainline release.

The longer answer is that we can piece together a good picture using information from the two sources you linked. They are actually my two "go to" locations for deciphering this information.

First, according to the page you linked from Michael Luo over at UC Corner, we get a picture of how Cisco is structuring the CUCM/Unity Connection/Presence/UCCX build numbers:

On each sub-version, there are also "build-numbers". e.g. 6.1.2.1000, 6.1.2.2000, etc. Build-number is the most confusing part.

Generally speaking, build numbers should increase in 1000, such as 6.1.2.1000, 6.1.2.2000, etc.

CUCM is built on Linux OS. Whenever Cisco release an OS security patch, they'll increase the build number by 1000. This is called PSIRT patch.

Remember CUCM is an application running on Linux. OS patch does not contain any CUCM bug fixes. Any bug fixes would be in ES (Engineering Special). ES versions would be indentified by the last three digits in build numbers (e.g. 6.1.2.1112)

Secondly, from the CUCM Software Compatability Matrix PDF, (sourced from Cisco Support documentation here), we can find a rough guide of what CUCM Version Number matches which System Version number. This has always in my experience proved to be an accurate guide.

For example:

CUCM Version    |    System Version
-----------------------------------
9.1(1a)         |    9.1.1.20000-5
9.1(1)          |    9.1.1.10000-11
9.0(1)          |    9.0.1.10000-37
8.6(2a)SU3      |    8.6.2.23900-10
8.6(2a)SU2      |    8.6.2.22900-9