Cisco 8800s not registering with CUCM

[Bitcoin]

Ladies and Gents,

So I have a very interesting problem.  I manage quite large organization where users can buy their own devices.  We tell them to buy the appropriate TAA devices and models.

We got a shipment of 200 8800s a year ago.  Everyone of these devices can register without issue.

My team has tried to do 2 separate installs with 8841s/8811s to find they do not register.  These devices have been sourced from Mexico with a manufacturing date of the last couple months.

The common denominator we have is older manufacturing dated phones register with no problem.  Newer manufacturing dated phones dont.

Both have the "Use 12.7 or later" stickers.

What RTMT report can I look at for this?

Or has anyone ran across a similar issue?

[Roger Kallberg]

You should look at the call manager SDL traces.

[Jonathan Schulenberg]

Also ensure these phones are running CUCM/CME enterprise firmware and not the MPP firmware used with everything else; the latter includes “3PCC” in the Product ID / SKU.

CUCM SDL traces will show why CUCM rejected it - if the phone made it that far. Phone console logs would help you understand why it may not have made it that far, eg no DHCP Option 150, ITL trust failure,  or no response from CUCM TFTP (technically HTTPS for those models).

[Bitcoin]

Yeah. Same switch, port, VLAN etc.  One non-MPP phone will register.  Another newer non-MPP phone will not register. 

Transport/DHCP is 100% okay.  I will look into the SDL traces.  Do not think I have ever got into that.

[Bitcoin]

Roger...appreciate the response. I am going to dive into the SDL traces.  I don't think I have looked at these before.

[Roger Kallberg]

Then you’re in for a treat. It takes a pit of brain power to process these, but they do include a lot of good information.

[Nithin Eluvathingal]

That label is the minimum firmware version required for the phones to register.

make sure your firmware meet that requirement.

[Bitcoin]

***UPDATE

Using a packet capture I see a request for a 12.6 load that returned a message saying it wasn't available. After adding the COP and restarting TFTP the phones started upgrading to the 12.6 then subsequently upgraded to the latest sip88xx.14-2-1-0001-14.  So now all the 8800's are on the new firmware.  I did a packet capture after this update and it didn't point to anything.  Cisco TAC doesn't see anything obvious either.  Their last reply was:

I found a config file that was sent to the device, but does not contain enough information (seems to be incomplete):

<device xsi:type="axl:XIPPhone" ctiid="6130" uuid="{9d2768c8-d636-5210-3b94-e9ff69267be3}">

<fullConfig>False</fullConfig>

<loadInformation>sip88xx.12-6-1-0001-668</loadInformation>

<ipAddressMode>0</ipAddressMode>

<capfAuthMode>0</capfAuthMode>

<capfList>

<capf>

<phonePort>3804</phonePort>

<processNodeName>XXXXXXXXXXXXXXXXXXX</processNodeName>

</capf>

</capfList>

<certHash></certHash>

<encrConfig>true</encrConfig>

</device>

Again this is only on newly manufactured phones.  Older manufactured phones are on the same firmware and are registered. 

[Bitcoin]

So I am still in the middle of a TAC Case.  What I have determined is that the phones are seemingly not coming with an LSC/MIC.  So I first have to upgrade VIA Null String then upgrade to the CAPF file.  This allows the phone to register.  Cisco TAC verified my RTP certs are good to go so something else is going on here.

[Jonathan Schulenberg · Accepted solution]

LSC and MIC are two different things. The former is issued by CAPF while the latter is burned in at the factory. If you have mixed mode enabled with TFTP encryption that would explain why the config file is incomplete; the unencrypted portion of it is just a stub file with the bare minimum info. Please mention that you are running mixed mode with CAPF on future posts; very few customers use that feature.

I'd seriously consider RMAing the phones if they do not have MIC. That's a serious miss, if that is what actually happened. It seems more likely that their MIC was issued by a newer CA that is missing from your CAPF-trust store. They won't be able to get their LSC without a MIC unless you use an auth string (difficult to scale, but safe if handled out of band properly) or null string (super insecure).

[Bitcoin]

Yeah. I do not believe that there is a missing MIC. Doesn't make sense to me but it is acting as if it is. Cisco Tac verified certificates are good to go in that regard. Now I am possibly second guessing Tac's assumption there. Appreciate the comment.