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'.
sccp ccm 10.9.12.1 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.
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.
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.
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 220.127.116.11) the phones are showing the same behaviour as you described.
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
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:
switchport access vlan 2
switchport mode access
switchport voice vlan 100
switchport port-security maximum 2
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
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
macro description cisco-phone
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
 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.