CUCM - New phones being rejected v11.5

[dtcobra22]

Hi all,

I require assistance (I have a ticket raised with Cisco but they're not returning any of my messages and it's been a few days). Whenever I add a new phone the registration ID becomes rejected straight away. The phone is assigned an IP but wont register.

We have purchased 45 Enhanced Plus licenses, and we're currently using 15 licenses (2 phones per license, total of 30 phones). If I go to System>Licensing>License Usage Report, I can see 15 Enhanced licenses being used. Now, if I open Cisco Prime License Manager, and I go to License Usage, it also shows 15 'required' licenses. When I go to Planning and create a new License Plan, it says that I have 45 Licenses installed, 15 are required, and 30 are available. I only started to see this rejection error on the 16th License that I tried to use. 

I asked Cisco how to add more licenses from the pool of 30 available that I have, and they said to create a new 'End User' in CUCM Admin. I did this, and any phone I attached to that license becomes rejected. If I remove that phone from CUCM and re-add it (without connecting the phone to the network) it's automatically rejected. CUCM must cache the MAC of that phone (Cisco 8841), to which I don't know how to flush. 

Any suggestions? 

Thank you!

[Chris Deren]

This is not licensing issue as insufficient licenses will not cause phones to not register, it would disallow you to configure one in CUCM.

Which phone models are you using?  Did you try to perform factory reset to ensure the ITL certs are deleted?

What message do you see on the phone "status" pages?

[dtcobra22]

Hello,

We're using Cisco CP-8841 phones. 

I just took 2 brand new 8841's out of the box and connected them at my desk where my original 8841 was connected and they're getting rejected. The status messages on these phones all say the same thing and that is:

- ITL Installed

- File not found : SEP**mac**.cnf.xml.sgn

- XMLDefault.cnf.xml.sgn(HTTP)

If I connect my original 8841 to my desk, it registers and works. 

If I remove a new phone from the CUCM register and re-add it (without connecting it to the network at all) it's automatically rejected. At this point it hasn't even been assigned an IP address. Once I connect it, it receives an IP which I can reach, but phone remains rejected.

I don't understand why some 8841's work and new ones do not. I super-copy the config of a working 8841 and change the DN and MAC as required, but doesn't register

[Chris Deren]

Cisco CUCM will reject phone registration from phones with ITL certificate of another cluster, this is called security by default and sounds like you may have a batch of phones that came with ITLs from another cluster, i.e. Cisco testing. Can you please perform a factory reset? Easiest way is let the phone boot up and then press the Settings button --> Admin Settings --> Reset Settings --> All Settings to see if that resolves your registration issues.

[dtcobra22]

Hi Chris,

Much appreciate you help with this.

I've performed factory reset on these phones several times.

I have just lined 2 phones next to each other, one that is working and another that isn't working so I can compare the phone information.

The phone that isn't working I can see doesn't have the Active or Standby Server listed and the last update was 2015, whereas the phone that is working lists both servers and the latest update was 2017.

Any reason why new phones are not automatically updating? They're assigned IP's.. 

[Chris Deren]

Are they getting correct TFTP server from the DHCP scope?

Is the TFTP service running on the TFTP CUCM node(s)?

Can you pull SDL trace from CUCM to see if CUCM is getting SIP REGISTER messages and how it responds?

[Jaime Valencia]

Look at the FW version you're pushing from CUCM to those devices, and make sure there's no need for a middle step in the upgrade in between the version they currently have, and what CUCM tells them to use.

[dtcobra22 · Accepted solution]

So the issue has been resolved. I powered off our publisher/subscribers and booted them back up in sequance from publisher and than the subscribers. We had a power outage a week ago and ever since we've had these issues. I'm not sure if they need to be powered up in sequence or not, but it solved it haha. Thank you everyone for your responses. Much appreciated.

[Cleo Jamison]

I'm having the same issue.
Did you get the issue resolved?

[JH51928]

Hello,

I'm also having issues registering the phones but mine is in the same cluster.

We successfully upgraded our CUCM from 11.5 to 12.5 a week ago. 

CUCM cluster filled up the active partition to 98% after the upgrade and TAC advised us to rebuild using 7500 users OVA so we can have 110GB space. 3 days ago I rebuilt the secondary subscriber using DRS restore, a day after I rebuilt the primary subscriber using DRS restore, then a few hours later, we found out that all phones are getting rejected. When we run show itl, its says ITL was last modified on thursday Aug 13 22:50. I'm not sure but that could be the time I was rebuilding the primary subscriber.          

All phones are stuck registering

-I looked at the RTMT, it says rejected, dbinfoerror.

-Phones are getting ip address from DHCP server

-In syslog, it shows "ITL are updated or installed" on the phones.

-Call Manager and TFTP service on our publisher, primary subsciber, and secondary subscirber are running.     

-We tried deleting the ITL on phones, it didn't work, same issue

-We tried rebooting the servers in the cluster, it didn't work, same issue

-We tried replacing the ITL file by running utils itl reset localkey, it didn't work, same issue.

Please help, this has been communicated with TAC yesterday morning already but they did not get the chance to get back to me.

[pengchengyu1795]

About that I also have a question : does WebX registration need special license?

[Jonathan Bauer]

I know this is an old post but I am posting just for others who may have the same issue.

I recently ran into a similar issue where none of our phones would auto register and we had actually used up all of our numbers set aside to auto register. After cleaning up the cluster everything began operating as normal. For relevance, we used both 79XX and 88XX series IP phones.

Hope this helps someone!