8821 Phones failing to re-register after reboot

[NPM]

Hi,

As per the title, we have an issue with phones failing to register if they leave the network due to their location (then return) or rebooting.  What I see as strange is that other phones that have remained in the network are fine.

The defective phones network configuration is correct and they are connected to the network and accessible via http.  
Both TFTP servers are listed on the phones.
I restarted the TFTP service on both servers to see if that would make a difference but it didn’t.  

There have been no recent changes before this issue.

I tried installing RTMT to gain some extra insight but it installs with errors every time (log file says “ERROR while attempting to execute the installation script” when the install attempts to update time zones tables on Machine and when copying security jars onto windows machine.  It’s also unable to create the desktop shortcut).

My knowledge of CUCM is fairly basic so any help would be appreciated.

Thanks 

Edit: CUCM version 11.5.1.10000-6

[Leo Laohoo]

---

@NPM wrote:
if they leave the network due to their location (then return)

---

The 8821 has many design "bugs" and one of them is the way the wireless NIC handles the out-of-range (OoR) situation.  Regardless what version is loaded into the phone (and I have tested & used them all!), it will eventually crash the wireless NIC of the phone when the phone leaves WiFi coverage.  There is no visible cues what the state of the wireless NIC is doing.  Our recommendation to our 8821 users is simple:  Turn off the phone if going OoR otherwise reboot the phone regularly.  

[NPM]

Hi Leo, thanks for you reply. 

Noted regarding the NIC although I haven’t seen issues with that before.  Not to say they won’t arise in future though. 

In this case a reboot of the phone is actually causing the issue to identify itself.  If I take one of the phones that are connected and working and reboot it, it will lose registration and fail to register upon restart.  It just shows as “unregistered” in CM

[Leo Laohoo]

---

@NPM wrote:
In this case a reboot of the phone is actually causing the issue to identify itself.  If I take one of the phones that are connected and working and reboot it, it will lose registration and fail to register upon restart.  It just shows as “unregistered” in CM

---

I take it the phone(s) reboots and successfully join the WiFi.  Is my assumption correct?

[NPM]

Yes that’s correct. All network configurations are correct and the phone is accessible via http.

we also have 8811 phones in the system and as a test this morning I unplugged the network cable to one, allowing it to power down.  After re-connecting again the phone display remains stuck on “registering phone”.

[Leo Laohoo]

What firmware is the phone on?

If the APs are Cisco, what is the model of the APs, what firmware is the controller on?

[NPM]

8821: 11-0-6-7

8811: 12-0-1SR1-1

cisco Air-Cap2702I-K-9 APs on a 5520 controller running 8.10.171.0

I don’t believe it’s related to the wireless network though as the wired phones are also affected.

Looking at the logs the phone is getting as far as receiving the configuration file so network communication must be fine? 

[Leo Laohoo]

11.0(6)SR2 is what we use on our 8821.  Upgrade to this version and see if it improve things. 

If it still does not, do a debug on CUCM.

[NPM]

Is there a way to debug without rtmt?

[Leo Laohoo]

Pull the logs and debug files off the phone.

Upload 11.0(6)SR2 via IP or cable.

[mradell]

We had tons of issues with 8821s in our environment and updating firmware helped a lot. We're currently running sip8821.11-0-6SR4-3 on the phones and it seems to work well. In general though, 8821s are, in my personal opinion, hot steaming garbage. They are close to EOS/EOL as well (https://www.cisco.com/c/en/us/products/collateral/collaboration-endpoints/unified-ip-phone-8800-series/cp-8821-phone-eol.html) so I'd start planning on replacing them in your environment sooner rather than later.

[NPM · Accepted solution]

Just for info it turned out to be an expired certificate in CM which was being used for encryption between phones.