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
end
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
regards,
David.
[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.
