Table Of Contents
Cisco IP Phone 7960 and 7940 Firmware Upgrade Matrix
Signed and Unsigned Images (Image Authentication)
Original Boot Mechanism for Firmware Image Selection
Secure and Nonsecure Configuration
Troubleshooting Upgrades on the Console
Cisco IP Phone 7960 and 7940 Firmware Upgrade Matrix
November 13, 2006
This document contains information about upgrading application firmware for the Cisco IP Phone 7960 and 7940. The information in this document is updated regularly. Use this matrix in conjunction with the documents listed on following indexes:
•SCCP— Skinny Client Control Protocol (Cisco IP phone documentation for Cisco IP Phone 7960G and 7940G)
•SIP—Session Initiation Protocol (Cisco IP phone documentation for SIP)
•MGCP—Media Gateway Control Protocol (Cisco IP phone documentation for MGCP)
Contents
•Signed and Unsigned Images (Image Authentication)
•Original Boot Mechanism for Firmware Image Selection
•Secure and Nonsecure Configuration
•Troubleshooting Upgrades on the Console
Firmware Protocols
The Cisco IP Phone 7960 and 7940 platform has the ability to support three protocol application firmware versions:
•SCCP—Used with Cisco Call Manager.
•SIP—Used with Cisco SIP Proxy Server (CSPS), base transceiver station (BTS), third-party servers, or as a standalone entity.
•MGCP—Used with third-party call agents (CAs).
The ability to load a specific protocol is done through a dual-boot mechanism, which allows for platform flexibility and return on investment.
Firmware Naming Conventions
Early Versions
The first versions of application firmware for SCCP and SIP had image names that used an "8.3" format. The following conventions were used:
•SCCP firmware—P003xxyy.bin
•SIP firmware—P0S3xxyy.bin
In both bases, x represents the major version, and y represents the minor version. The third character represents which protocol firmware version is running.
Current Versions
In current versions, the following conventions are used:
•SCCP firmware—P003xxyyzzww.bin, where x represents the major version, y represents the major subversion, z represents the maintenance version, and w represents the maintenance subversion.
•SIP firmware—P0S3-xx-y-zz, where x represents the major version, y represents the minor version, and z represents the subversions.
•MGCP firmware—P0M3-xx-y-zz, where M is the third character. The major, minor, and subversions for MGCP are consistent with the SIP naming convention.
Table 1 contains firmware naming convention examples.
Signed and Unsigned Images (Image Authentication)
There are two types of images that are used on the Cisco IP Phone 7960 and 7940: signed and unsigned. Image authentication is done through signed binary files. Signed images have a .sbn extension, while unsigned images have a .bin extension.
Image authentication requires that the binary image not be changed prior to being loaded into the phone. Versions prior to 5.x accept unsigned binary files.
Version 5.x and later images accept only signed binary files, which improves security on the Cisco IP Phone 7960 and 7940. However, the use of signed binary files does not allow you to return to an earlier software version. Once a Version 5.0 firmware image is installed, for instance, regardless of protocol, it cannot be replaced with any previous version. The firmware image can be replaced only with another signed image 5.x or later. All versions prior to a Cisco IP Phone 7960 and 7940 Version 5.0 will not load onto the phone after it is installed.
Original Boot Mechanism for Firmware Image Selection
A protocol boot mechanism is used to select the firmware image. During the phone bootup, regardless of protocol, the first file requested is the OS79XX.TXT file. The OS79XX.TXT file includes a line that contains the image name of the protocol that you select to run. For example, the image should read P003xxyyzzww for SCCP, P0S3-xx-y-zz for SIP, or P0M3-xx-y-zz for MGCP.
The phone uses the first four characters in the image name of the OS79XX.TXT file to determine how to load the image. If the first four characters match, the universal boot mechanism is bypassed and the phone continues with its current protocol boot sequence. However, if the first four characters do not match (namely the third digit, which represents the protocol), the universal boot mechanism will attempt to load the new protocol image that has been defined in the OS79XX.TXT file.
Universal Application Loader
The universal application loader allows for additional phone features to be added across all protocols. This feature also eliminates the need for a separate OS79XX.TXT file, which used to be required for booting between protocols.
The universal application loader operates in a manner very similar to the older SCCP, SIP, and MGCP systems. It relies on a TFTP server to supply information in text files known as "configuration files." The information in these files points to a new loads file, which contains the names of the desired application image and universal application loader. This system allows the universal application loader to know which image revision is desired in the phone. Once this information is known, the phone has the ability to upgrade itself and the application image as needed.
The universal application loader allows the system administrator to use SCCP, SIP, and MGCP, on the same network. To do this, a hunt algorithm is employed that searches for multiple configuration files. Depending on which configuration file is found first, the phone will automatically select that protocol. The hunt algorithm ensures that the administrator can assign a specific protocol to a specific phone. The hunt algorithm searches for files in the following order:
1. CTLSEP MAC File—For example, CTLSEP003094C25D2E.tlv. See the "Secure and Nonsecure Configuration" section.
2. SEP MAC File—For example, SEP003094C25D2E.cnf.xml.
3. SIP MAC File—For example, SIP003094C25D2E.cnf.
4. MGCP MAC File—For example, MGC003094C25D2E.cnf.
5. XML Default File—For example, XMLDefault.cnf.xml.
6. SIP Default File—For example, SIPDefault.cnf.
7. MGCP Default File—For example, MGCDefault.cnf.
The universal application loader is also capable of searching multiple servers to find the configuration files, using DHCP, manual settings, and Domain Name System (DNS). The configuration file can also contain a dynamic_tftp address, which will force the phone to use a different server.
If the universal application loader exhausts all possible servers and still cannot find any configuration files, it will assume that the application image in flash memory is correct and will launch it. If it cannot find an application image in flash memory, it will stop and display "No Load Specified" on the screen.
The loads file contains the universal application loader and the application image, as well as an LA_VERSION command (used to determine if the universal application loader needs to be upgraded). The universal application loader is identified by its extension (.sbn), which indicates that it is signed. The signed application image is identified by a .sb2 extension. The loads file itself is also signed and has a .loads extension.
The universal application loader for SIP and MGCP is delivered in a zip file that is posted to Cisco.com. For SCCP, the universal application loader is automatically installed as part of the executable phone_load install wrapper used on the Cisco CallManager.
The zip file for SIP and MGCP contains five files:
•OS79XX.TXT—This file will now always contain the universal application loader image.
•P003.........bin—Nonsecure universal application loader for upgrades from pre-5.x images.
•P003.........sbn—Secure universal application loader for upgrades from images 5.x or later.
•P0a3.........loads—File that contains the universal application loader and application image, where "a" represents the protocol of the application image loads file: 0 for SCCP, S for SIP, and M for MGCP.
•P0a3.........sb2—Application firmware image, where "a" represents the application firmware image: 0 for SCCP, S for SIP, and M for MGCP.
Note The [....] above are used for representing the naming convention for the universal application loader. This image should not need to be changed. (This image is not associated with the application firmware image.) For example, a SIP zip file would have the following naming convention: OS79XX.TXT, P003.........bin, P003........sbn, P0S3-xx-y-zz.loads, and P0S3-xx-y-zz.sb2. An MGCP zip file would have the following naming convention: OS79XX.TXT, P003.........bin, P003........sbn, P0M3-xx-y-zz.loads, and P0M3-xx-y-zz.sb2. Notice that the universal application loader always maintains an SCCP naming convention but is not tied to a particular protocol.
The *.loads and filenames *.sb2 are based on the protocol that is used; each zip file will display these two differently.
Secure and Nonsecure Configuration
The Cisco IP Phone 7960 and 7940 platform supports configuration-file authentication, certificate installation, and device authentication with the call control unit. By default, the phone is nonsecure until the phone detects that it needs to take additional steps to configure itself in secure mode. The initial step in this determination is through a CTLSEP MAC file request upon bootup (for example, CTLSEP003094C25D2E.tlv). The CTLSEP MAC file is a certificate trust list, which if populated, contains information about the servers to which the phone is attempting to connect and whether the server connection will be secure or nonsecure.
The CTLSEP MAC file is the first file requested in the universal application loader, followed by the additional six configuration files in the hunt algorithm defined in the "Universal Application Loader" section. If the CTLSEP MAC file is present, the phone proceeds with additional security actions regarding phone and server communication; if the CTLSEP MAC file is not present or is empty, the phone proceeds in nonsecure mode with the hunt algorithm.
Shipped Firmware Images
The image that is loaded on the phones and that is shipped from manufacturing is an unsigned SCCP image (P0030301MFG2) that will universally boot to any image in Table 2.
Upgrading Firmware Images
Use the information in Table 3 to determine which firmware image you should upgrade to. Refer to the recommended procedures for each phone and image.
Table 3 Firmware Upgrade Scenarios
Current Image on Phone Upgrade to This Phone Image Upgrade ProcedureP0030301MFGx (image shipped from manufacturing)
Any SCCP image
P0030301MFGx (image shipped from manufacturing)
SIP or MGCP images 6.x or earlier
P0030301MFGx (image shipped from manufacturing)
SIP or MGCP images 7.x or later
SCCP images 3.x or earlier
Any SCCP image
SCCP images 3.x or earlier
SIP or MGCP images 6.x or earlier
SCCP images 3.x or earlier
SIP or MGCP images 7.x or later
SCCP images 5.x
SCCP images 5.x or later1
SCCP images 5.x
SCCP images 5.x
SIP or MGCP images 7.x or later
SCCP images 6.x or later
SCCP images 5.x or later1
SCCP images 6.x or later
SIP or MGCP images 5.x or 6.x1
SCCP images 6.x or later
SIP or MGCP images 7.x or later
SIP images 4.x or earlier
SCCP images 5.x or earlier
SIP images 4.x or earlier
SCCP images 6.x or later
SIP images 4.x or earlier
SIP or MGCP images 6.x or earlier
SIP images 4.x or earlier
SIP or MGCP images 7.x or later
SIP images 5.x and 6.x
SCCP images 5.x or later1
SIP images 5.x and 6.x
SIP or MGCP images 6.x or earlier
SIP images 5.x and 6.x
SIP or MGCP images 7.x or later
SIP images 7.x or later
SCCP images 5.x or later1
SIP images 7.x or later
SIP or MGCP images 7.x or later
MGCP images 4.x or earlier
SCCP images 5.x or earlier
MGCP images 4.x or earlier
SCCP images 6.x or later
MGCP images 4.x or earlier
SIP or MGCP images 6.x or earlier
MGCP images 4.x or earlier
SIP or MGCP images 7.x or later
MGCP images 5.x and 6.x
SCCP images 5.x or later1
MGCP images 5.x and 6.x
SIP or MGCP images 6.x or earlier
MGCP images 5.x and 6.x
SIP or MGCP images 7.x or later
MGCP images 7.x or later
SCCP images 5.x or later1
MGCP images 7.x or later
SIP or MGCP images 5.x or later1
1 Image authentication does not allow for downgrades to versions earlier than 5.x once a 5.x image is on the phone.
2 If you want to upgrade from SIP 5.x or 6.x to SIP 7.x, use Procedure F. Upgrading from SIP 5.x directly to SIP 7.x is not possible. First upgrade to SIP 6.3 and then go to SIP 7.x
Procedure A
The SEP<mac-address>.cnf.xml file is downloaded when a phone is reset. This file contains the load_information tag that tells the phone which image it should be running. If the image load differs from the one currently loaded on the phone, the phone contacts the TFTP server to upgrade to the new image.
Procedure B
1. Copy the desired binary image from Cisco.com to the root directory of the TFTP server.
2. Open the OS79XX.TXT file with a text editor and change the file to include the desired image.
3. Specify the desired image in the protocol configuration files.
4. Reset each phone.
The phone contacts the TFTP server and requests its configuration files. The phone compares the image that is defined in the configuration file to the image that it has stored in flash memory. If the phone determines that the image in the configuration file differs from the image in flash memory, it downloads the image in the configuration file (which is stored in the root directory on the TFTP server). Once the new image has been downloaded, the phone programs that image into flash memory and reboots.
Procedure C
Specify the image in the configuration file image parameter for the protocol that is being upgraded to (load_information for SCCP or image_version for SIP and MGCP). Remove any protocol configuration files that are not used for the specified protocol.
For example:
•SCCP—For SCCP, the SEP<mac-address>.cnf.xml file is downloaded when a phone is reset. This file contains the load_information tag that tells the phone which image it should be running. If the image load differs from the one that is currently loaded on the phone, the phone contacts the TFTP server to upgrade to the new image.
•SIP—For SIP, the SIPDefault.cnf and SIP<mac-address>.cnf files are downloaded when a phone is reset. This file contains the image_version parameter that tells the phone which image it should be running. If the image load differs from the one that is currently loaded on the phone, the phone contacts the TFTP server to upgrade to the new image.
•MGCP—For MGCP, the MGCDefault.cnf and MGC<mac-address>.cnf files are downloaded when a phone is reset. This file contains the image_version parameter that tells the phone which image it should be running. If the image load differs from the one that is currently loaded on the phone, the phone contacts the TFTP server to upgrade to the new image.
Note For a single step upgrade from an SCCP image to a SIP or MGCP image (manufacturing images, for example) the loadInformation tag in the XML Default.cnf.xml file must reflect the Universal Application Loader Image (P003-xx-y-zz). This step is in addition to the steps listed above for SIP and MGCP. For example:
<loadInformation8 model="IP Phone 7940">P003-07-4-00</loadInformation8>
<loadInformation7 model="IP Phone 7960">P003-07-4-00</loadInformation7>
Procedure D
For SCCP images 6.x or later and for SIP or MGCP images 7.x or later, use the universal application loader and follow these steps:
1. Unzip the software_version.zip file in the root (top level) TFTP directory.
2. Reset the phone.
The phone contacts the TFTP server and requests its configuration files. The phone compares the image defined in the OS79XX.TXT and protocol configuration files to the image that it has stored in flash memory. If the phone determines that the image defined in the files differs from the image in flash memory, it downloads the image that is defined (which is stored in the root directory on the TFTP server). Once the new image has been downloaded, the phone programs that image into flash memory and reboots.
Procedure E
There are two possible ways to accomplish the upgrade.
1. Create the configuration file for the desired protocol on the TFTP server that has been specified in the phone and remove all other protocol configuration files. In this configuration file, specify the image using the load_information tag (SCCP) or the image_version tag (SIP and MGCP). Reset the phone.
For example, if the image on the phone is SCCP and the image desired is MGCP, create an MGC<mac-address>.cnf or MGCDefault.cnf configuration file with the image_version set to the desired image; remove all other protocol configuration files for this phone.
2. Using the configuration file for the protocol that the phone is currently running, change the image in the load_information tag (SCCP) or the image_version tag (SIP and MGCP) to represent the protocol that is chosen to run.
For example, if the image on the phone is SIP and the image desired is SCCP, change the image_version parameter to reflect the SCCP image (P00306000200).
Procedure F
1. Upgrade to the 6.3 image first using Procedure B.
Then
2. Upgrade to the desired image using Procedure D.
Troubleshooting Upgrades on the Console
Use the information in this section to troubleshoot your upgrade.
Common Error Messages
Protocol Application Invalid
This error message means that the application image cannot be loaded into flash memory or that the image does not exist in flash memory. This can happen for the following reasons:
•The zip package was not unzipped in the root TFTP directory.
•Files were copied to the TFTP server instead of using the zip package.
•The universal application loader was unable to load a new application image into flash memory (image authentication failure, nonexistent image, TFTP errors, and so forth).
Image Authentication Failed
This error message means that the new application image that is about to be downloaded has failed the signature check.
No Load Specified
This error message means that the application image cannot be loaded into flash memory when there is no image in flash memory. This occurs when there is no image specified in any of the configuration files.
Troubleshooting Tips
•To resolve image authentication and zip file issues, ensure that the image is extracted from the zip file and that the image is not copied to the TFTP server.
•To resolve application image issues, add the desired image to the configuration files and reboot the phone to cause the application image to download.
•To troubleshoot a failed upgrade attempt, run a sniffer capture.
•To assist with any further errors or failed upgrade attempts, the RS-232 port on the phone provides console access for troubleshooting and debugging. Refer to the console access documentation located at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipp7960/admin/index.htm
Related Documentation
Copyright © 2004 Cisco Systems, Inc. All rights reserved.