This document describes some aspects of support for Cisco IP Phones related to the firmware, such as phone load.
This document is applicable to these desktop and wireless Cisco IP Phones (this is not a complete list):
- Cisco Analog Telephone Adaptor (ATA) 180 Series
- Cisco Cius
- Cisco Desktop Collaboration Experience DX Series
- Cisco IP Phones 7800 Series
- Cisco Unified IP Phones 6900 Series
- Cisco Unified IP Phones 7900 Series
- Cisco Unified IP Phones 8800 Series
- Cisco Unified IP Phones 8900 Series
- Cisco Unified IP Phones 9900 Series
- Cisco Unified Session Initiation Protocol (SIP) Phones 3900 Series
For the purposes of this document, a phone model refers to a discrete identifier, such as 9971 or DX650.
Support Clarifications for IP Phone Firmware
This section clarifies the type of support that Cisco provides for IP Phone firmware.
- For each IP Phone model, once Cisco releases a new firmware version, the older versions are no longer supported. For example, if the current 9971 firmware load is Version 9.3(4), and Version 9.4(1) is released, then Version 9.3(4) is no longer supported.
- The latest release for a particular phone model is always the highest-numbered version available for download on Cisco.com. A higher-numbered firmware release for one model does not affect firmware support for another model.
- Engineering Specials (ES) are created for critical customer fixes on the currently-supported release. Once a new firmware release is available, no additional ESs are created for the older release. Future ESs are only created for the new release. ES loads applied to a released image are not necessarily included in the next released image if they are created after the code freeze date. For that reason, the ES loads might not appear in the release until two releases after the initial distribution of the ES.
- Cisco expects customers who encounter a problem on an older version of firmware to test the latest firmware on a subset of phones in order to confirm that the problem still exists.
What Does Supported Mean?
In general, there are always four dimensions of support to consider. They are listed here in the form of questions, with answers specific to Cisco IP Phones.
Does it work?
There are many items that work, but are not necessarily allowed or validated by Cisco. Therefore, no technical assistance is provided. That it works is necessary, but not sufficient.
Do the vendor support policy rules allow it?
Cisco defines what is allowed in the Product Data Sheet and in the Release Notes for a given firmware version. For Cisco IP Phones, an item that is not allowed even if it works is usually due to one of these reasons:
- It creates an application problem that can only be fixed with software enhancements or re-architecture; for example, certain features might not be available when Cisco IP Phones are used with third-party call control.
- It can negatively impact application stability or predictable capacity/performance, and the required Cisco validation has not yet occurred; an example is the use of third-party access points in order to provide wireless connectivity for wireless Cisco IP Phones.
- A valid usage scenario does not exist for Cisco Collaboration. An example is the registration of Cisco IP Phones directly to Cisco Unified Communications Manager (UCM) over the Internet without the use of appropriate security and encryption.
If it is allowed, did the vendor validate it?
Here are some examples:
- Formal testing and assurance, which is particularly important for Cisco Unified Communications (UC)/Collaboration deployments of real-time voice and video
- Customer contact centers
- Other mission-critical communications
Some allowed items are not validated, either because they are outside the responsibility demarcation for Cisco, such as interoperability with third-party devices, or because they are outside the scope of what Cisco explicitly tested, such as the use of older phone firmware with newer versions of UCM.
Does the vendor provide technical assistance for how-to or break-fix?
For example, is assistance provided for a configuration or for a troubleshoot procedure that aims to establish the root-cause and fix for a problem. Fixes for new software defects might only be provided as an update to the latest version of the software. The Cisco Technical Assistance Center (TAC) supports products purchased from Cisco with a valid maintenance contract that is paid in full.
There are several milestones in the product End-of-Life (EoL) process that can impact the types of support that the Cisco TAC can provide for a product. Cisco IP Phones rely on the Cisco Unified Communications Manager (CUCM) for almost all of their functionality, so the support status for that product must be considered when you troubleshoot an issue on a phone.
When a phone reaches End of Software Maintenance (EoSW), it means that Cisco is not obligated to release any further software updates for that model. There might be exceptions made for critical vulnerabilities, but these are always evaluated on an individual basis. The Cisco TAC will work on cases for products that have reached EoSW, but if a problem is discovered with the phone software, it will not be fixed.
When a phone reaches the Last Day of Support - HW, it is considered obsolete and completely EoL. The EoL phones are not entitled to TAC support because it is not possible to purchase a support contract for any product after the end of the software contract renewal date.
The dependency of these phones on the CUCM comes into play for both EoSW and EoL phone models. The Cisco Unified Communications Manager Software Compatibility Matrix states:
Phone models that are End of Software Maintenance will continue to be supported on the latest UCM releases however they will not take advantage of any new UCM or firmware features associated with that release.
This statement applies to EoL models as well. This means that the TAC investigates problems that are related to an EoSW or EoL phone, as long as the customer has a valid support contract for the CUCM to which the phone is registered. If the problem is found to be due to a defect in the CUCM, then the TAC works with the customer and development in order to determine a workaround and long-term fix for the problem.
Here are some real-world support examples that illustrate these concepts:
- Cisco SIP phones that register with third-party call control. While Cisco makes every effort to ensure its phones are SIP standards compliant, it does not validate, provide configuration guidance, or software support for third-party call control solutions, except where explicitly documented.
- A daisy chain of multiple phones via the network and PC ports. This works to some extent, because it allows the phones to register and make basic calls; however, it does not provide production-class stability and adherence to documented network security and Quality of Service (QoS) best practices.
- Certain hardware revisions only work with newer firmware. Occasionally, Cisco must update hardware components in currently-shipping IP Phone hardware. Software updates are sometimes required in order to support these new components, which do not allow the new IP Phone hardware revision to run older IP Phone firmware versions. Newer hardware model support is described in the release notes.
- A new defect is discovered in Version 8.5(2) but only fixed in Version 9.4(3). Cisco only maintains one active version of any phone firmware. A potential defect in Version 8.5(2) must be demonstrated to also occur in Version 9.4(3) before a bug fix is released. This fix could be released as Version 9.4(3)ES or Version 9.4(4).
- A change in the default Softkey Template in CUCM Version 10.5(2) prevents a 7936 Series phone from the use of the Conference feature. The 7936 Series phones went EoSW in 2011, long before the CUCM Version 10.5 was released. Because the problem lies with the CUCM Software, the TAC will work with customers in order to mitigate this problem.