Active Load ID vs Load ID

[Chin Jam]

Hi

I have a few hundred c7945 phones registered. The majority show the load/active IDs as follows:

Load ID - SCCP45.9-4-2SR1-1S

Active Load ID - SCCP45.9-4-2SR1-1S

I’ve noticed about 10 show the Active Load ID to be different:

Load ID - SCCP45.9-4-2SR1-1S

Active Load ID - SCCP45.9-0-3S

All phones are registered to the same CUCM server.

I’ve compared the Network Information from one of the phones running the older Active load with one running the current load:

The Unified CM 2 – shows an old retired CUCM server but CM 1 is current.

User Locale Version                        8.0.0.1(5) – the others show 11.0.0.0(1)

Network Locale Version                8.0.0.1(5) – the others show 11.0.0.0(1)

Any idea why these phones are not able to load the newer version?

Are these phone not able to install the SCCP45.9-4-2SR1-1S load because the version they are running needs an intermediate version update first before they can get to the SCCP45.9-4-2SR1-1S load?

From the phone web page

Status Messages:

7:07:23a Trust List Update Failed

7:07:31a TFTP Error : SEPECC882B129BB.cnf.xml.sgn

7:07:40a Trust List Update Failed

7:07:49a TFTP Error : SEPECC882B129BB.cnf.xml.sgn

7:13:49a Trust List Update Failed

7:13:57a TFTP Error : SEPECC882B129BB.cnf.xml.sgn

7:14:06a Trust List Update Failed

7:14:14a TFTP Error : SEPECC882B129BB.cnf.xml.sgn

1:23:33a Trust List Update Failed

1:24:04a Trust List Update Failed

Console Logs:

9:55:53a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

9:56:06a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

10:09:28a 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

1:14:07a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

1:14:07a 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

1:14:08a 7: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Timeout

1:14:18a 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

4:30:13a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

6:35:13p 17: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=KeepaliveTO

6:35:13p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:35:13p 17: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=KeepaliveTO

6:35:13p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:35:13p 17: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=KeepaliveTO

6:35:54p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

6:35:54p 18: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=Failback

6:16:40a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:16:40a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

6:16:40a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:16:40a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

6:00:46p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

6:00:51p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:01:04p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:12:02p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

6:12:02p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:12:02p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

6:12:02p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:12:02p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

3:11:21p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

3:11:26p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

3:11:39p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

3:21:06p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

3:21:06p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

3:21:06p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

3:21:06p 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

3:21:06p 14: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=UCM-closed-TCP

6:13:55a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

6:08:23a 25: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=Initialized

6:08:51a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

6:08:51a 25: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=Initialized

9:24:56a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

11:50:39a 10: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=TCP-timeout

11:50:50a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

11:51:21a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

7:14:15a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

7:14:15a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

7:14:15a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

7:14:15a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

7:14:15a 41: Name=SEPECC882B129BB Load= SCCP45.9-0-3S Last=IPv4 DHCP Timeout

1:23:54a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

1:24:25a 9: Name=SEPECC882B129BB Load= SCCP45.9-0-3S TFTP Error

[Nadav]

According to the release notes https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/7900_series/firmware/9_4_2SR2/english/releasenotes/P790_BK_C7078DFD_00_cisco-unified-ip-phone-7900.html:

For all SCCP firmware upgrades from firmware release versions earlier than 8.3(3) to Version 9.3(1) or later, you must first upgrade your phone firmware to an intermediate version (8.3(3) to 8.5(2)) and then upgrade to 9.3(1).

So your version is fine. No chance those phones are in the same site with a low bandwidth link towards their TFTP server, right?

[Chin Jam]

Thanks for the information Nadav.

There are other phones connected to the same switch which are running the newer version.  There is also nothing different in the config for interfaces that I can see.  If I reset the phone, they do not upgrade.

Is there any log file I can check or any suggestions?

Thanks,

CJ

[Nadav · Accepted solution]

Maybe the syslog or alternate syslog, either via CLI or RTMT.

If possible you could try factory resetting one of the phones. If it boots
up with the new firmware then the phone is fine and it was just a software
glitch. Then rinse and repeat.

[Jonathan Schulenberg]

This is likely an ITL problem. The phone won’t accept the new XML file including the current CCM nodes and firmware level because the digital signature of that XML file isn’t present in the ITL file on the phone’s flash. This happens if people move a phone to another cluster improperly or renew certificates without carefully reading the manual to get the sequence of events correct.

Try manually deleting the ITL from the phone and see if it fixes this.

https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116232-technote-sbd-00.html

[Chin Jam]

Hi Nadav - a factory reset fixes the issue and the phone updates it's software. The problem is that the phones are at remote offices and there is no way to do that through CUCM that I can find.

Thanks for the explanation Jonathan - much appreciated.

[Jonathan Schulenberg]

There are several third-party tools such as UnifiedFX PhoneView or their ITL Delete utility that is capable of clearing the ITL remotely, but only if the phone is actively registered to CUCM. They leverage, depending on your perspective, a loophole to the ITL/TVS validation logic: TAPI applications can pass XMLSDK commands using the Cisco TSP and a CUCM Application User with either Allow Control of All Devices or CTI Enabled with the phones directly associated. To my knowledge, there is no layperson writeup explaining the API calls involved in this; all of the vendors who have figured this trick out understandably want you to pay for their product.
https://www.unifiedfx.com/products/unifiedfx-phoneview