IP PHONE BACKWARD Compatibility

[ctamburello]

                   Hi,

a custiomer of mine has

N.01 - 7911

N.113 - 7912

N.16 - 7920

N.02 - 7936

N.08 - 7940

N.08 - 7941

N.1 - 7960

N.16 - ATA186

Running on a 4.2 calla manager.

He wants upgrade to Call manager 8.6 using MIG lic.

But he wants a kind of official Cisco Document where he can find the backward compatibility of the above mentioned IP PHONE and ATA

anyone can help me ?

CARLO

[Leonardo Tadeu]

Hello Carlo,

Take a lokk on this link, enter at the CUCM 8.6 version to see at types of devices this version support

http://tools.cisco.com/ITDIT/vtgsca/VTGServlet

Rate this if helps

Regards

Leonardo Santana

[p.mcgowan]

Hi Carlo,

You can check the CUCM compatability matrix;

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr1.pdf

this should tell you what is supported

Please rate helpful posts

[Rob Huffman]

Hi Carlo,

The existing phones will work and are supported but you will need to take precautions

as part of the process will upgrade their Firmware during the upgrade of CUCM to 8.6.

If you are running current Firmware on these phones it shouldn't be an issue

but if they are "old" then you will need to look at intermediate upgrade steps

before moving to 8.6

Let us know

Check Table 33 here.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr1.pdf

Cheers!

Rob

"May your heart always be joyful
May your song always be sung" - Bob Dylan

[bmccomb30]

Hi Rob,

A question related to your comments here is that I am wondering how I can prevent the phone firmware upgrade from happening during the CUCM upgrade so it can be scheduled later?  Is that possilbe?

Brad

[p.mcgowan]

Hi Brad,

One thing you can do to control the phone firmware upgrade is to upgrade the phone firmware BEFORE you upgrade the CUCM.

this way you can upgrade the phones in a controlled manner and make sure there are no issues with the phone before the big upgrade of the CUCM.

I would not recommend trying to prevent the phone from upgrading during the upgrade itself but if the phone is already running the latest firmware this removes any potential issue of upgrading a large number of phones at one time.

Please rate helpful posts

[Robert Thomas]

Brad,

There are workarounds you can use to prevent the phones from upgrading firmware during the upgrade process. This is usually the workaround I use, it might not work for every environment.

1) Deactivate all TFTP services on the cluster before the Switch version. This will prevent the phones from upgrading while the server reboots.

2) Go into device defaults, and change the device load name to the current firmware, to prevent the phones from upgrading.

3)Activate the TFTP services on the cluster again.

At a later point you can change the load name to the new firmware, and reboot the phones.

Personally I'm against artificially preventing the phones from upgrading the firmware, but I have instances where it was necesary.

[bmccomb30]

Thank you Robert and p.mcgowan those are both great ideas.  Much appreciated.