Showing results for 
Search instead for 
Did you mean: 

Cisco Community Designated VIP Class of 2020


6945 won't register to CME 9.0 (SCCP)

At core, the problem is that despite fetching the SEPaaaabbbbcccc.cfg.xml config file, it seems to be ignoring the <callManager/> element there.  At least, when browsing http://<phone>/NetworkConfiguration in frustration later, there are no values for 'CallManager 1' or 'CallManager 2'.

  IOS 15.2(3)T1

  CME 9.0

  sccp ccm identifier 1 version 7.0

  Firmware load SCCP 9-2-1-0

A couple of 8945's on the same subnet work just fine.

I found some similar threads to this, but they have not been marked as answered.

Everyone's tags (3)

6945 won't register to CME 9.0 (SCCP)

Try recreating the cnf files(no create cnf/create cnf) and see if that helps.  Make sure you have the model type applied correctly under the ephone config before doing this.


6945 won't register to CME 9.0 (SCCP)

Thanks for replying, although I had already tried that without success.

Amazingly, it was the 9-2-1-0 firmware distributed with the CME 9.0 download bundle that was faulty.

Firmwares 9-1-1-0, 9-2-2-4 and 9-3-1-3 all register with CME just fine after downloading their config files.  But 9-2-1-0 .... just doesn't.

6945 won't register to CME 9.0 (SCCP)

Hi David,

i have a similar issue with CME 9.1 and 15.2(4)M, the 6945s are registering only with 9-1-1, with every available higher release (9.2.1 and the phones are showing the same behaviour as you described.


6945 won't register to CME 9.0 (SCCP)

Hi Steffen,

I was going to call it a bug on 9.2.1 and get on with my life.  But if it's happening with later versions of everything for you, then I'll try to collect a few of my thoughts on it.  Maybe you will be motivated enough to chase it up.

First, I'd triple-check checksums of phone firmware loads on the tftp flash, and your PC's downloads folder.  I was all in a muddle, but I might have seen a problem there.  It's a low likelihood, but quick to check.

Secondly, I *know* that the phone doesn't even *attempt* to register, because I'm using both 'debug tftp server' (to know when I should expect the attempt to connect to port 2000) and 'debug ip tcp transaction' (to know if any such attempt is made). 

Thridly, it's unsurprising that it never makes the attempt, since even though it fetched its configuration file (proven with 'debug tftp events') it still doesn't have an address for a CallManager. BUT, I *know* that my CNF files are 'right', because I fetched them myself with a TFTP client, and made sure that the section of the .cnf.xml file (ie. the same one the phone asked for) was good[1].  (I didn't run 'em through an XML validator yet tho', or comprehensively cross-reference if *all* the values in the XML file made it to their relevant spots in the phone's config).

It seems for all the world like the phone *discards* the address of the CME server.  This characterisation is key to the problem I experienced.  Maybe the firmware has a dumb sense of what the CME server address 'ought' to be, or its view of the network is skewed by the particular phone it's on, or maybe the CME server address only gets read down one branch of the XML parsing code, or some other lame bug.

I suppose if one were to draw a long bow, it could be an XML parsing bug when certain phone firmwares read certain .cnf.xml files made by certain CME versions.  If XML parser libraries were known to be phone-hardware-version-dependent, that'd be an interesting line of enquiry.  It'd be even more damning if more than just the CallManager parameters didn't make it to the phone.  Yes, this seems unlikely, but it's something which we can observe, alter, and test in black-box fashion ... by comparing .cnf.xml files that work/don't work, and differences in .cnf.xml files generated by various versions of CME, and by running them through an XML validator.

Assuming the phone parses the .cnf.xml OK, then it's clear that the the phone firmware really is discarding the CallManager info for some reason.  If only we knew which reason!

Ultimately, my guess is that it is something specific either to a batch of phone hardware, or (most likely) there is something about the way the phone is attached to the network, which the newer firmware is not expecting.

My setup is:

  6945's have MAC's in the range:  e8b7.48ee.2___

  Attached to a Gi port on a SM-ES3G-24-P with 12.2(52)EX1 (ipbase)

  Which in turn is enclosed by a CISCO2911/K9 with 15.2(3)T1

  The Gi port configuration is typical from applying the cisco-phone macro:

interface GigabitEthernet0/9

switchport access vlan 2

switchport mode access

switchport voice vlan 100

switchport port-security maximum 2

switchport port-security

switchport port-security aging time 2

switchport port-security violation restrict

switchport port-security aging type inactivity

srr-queue bandwidth share 10 10 60 20

queue-set 2

priority-queue out

mls qos trust device cisco-phone

mls qos trust cos

auto qos voip cisco-phone

macro description cisco-phone

spanning-tree portfast

spanning-tree bpduguard enable

service-policy input AutoQoS-Police-CiscoPhone


In my scenario, my 3560 is routing for the phone's subnet (vlan 100), and thus the CME is not on on the same subnet as the phones themselves.  My sites were remote, and I wasn't in a position to alter the topology in this respect, but I'd be definitely trying it, if your topology is similar. 

That's about all I've got, sorry.  Hopefully this triggers a thought and sends you down a useful diagnostic path.  Please report back if you crack it!  Maybe Cisco will pay us lots of money to be a QA team on CME.  :-P



[1]  Hmm, or did I just do a 'more flash://cme/blah.cnf.xml?  I can't get a 7912 phone working with CME 9.0 at the moment, because when the TFTP client tries to fetch the firmware, the automatic TFTP binding *times out*.   Maybe CME fusses with automatic bindings somehow, and the pre-tftp and post-tftp versions of the .cnf.xml file should be checked.


6945 won't register to CME 9.0 (SCCP)

Ypu could try taking off the port security on the lan port.

I've just had a similar issue and it was the port security.

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here