Mike, here is what I know from documentation, sniffer traces and trial & error:
1) Phone is plugged in to data jack (Needs power)
Gets power either through in-line (loopback tone test generated from switch card or powered patch panel) or external transformer. If in-line power is provided the switch or panel will verify the devices power budget prior to sending the voltage (-48VDC).
2) CDP exchange happens which instructs the switch/panel about specific power requirements, preference in using Auxillary VLANs and the trigger field (which causes an immediate CDP exchange and bypasses the 60 second default).
3) Now the phone has power and knows what VLAN it should derive its IP Address from if using DHCP (Static is an option). The DHCP information must include option 003 - Router, then you may choose to send option 006 - DNS Servers and finally you should send either 066 or 150 for the TFTP Server (Call Manager) Address. I have been told option 150 is the recommended method, option 66 could be used by other devices and may cause conflicts.
4) Once the phone has its IP address it needs to register with Call Manager, which it does through tftp. The tftp addresses could be supplied in various ways (already discussed), but they are used in the following order (verified by Sniffer Traces): If all three options are being used (DNS(6), Bootp(66), 150) then option 150 is used. Basically if 150 is sent then phone will prefer it over all the other options. If 150 is not present and option 66 is being used then 66 will be used. By default the phone has CiscoCM1 in its first tftp address field, however, once the DHCP information is received and option 150 is present it will not use the name in order to find Call Maanager. If you have a distributed implementation with a centralized DNS its not a good idea to use name resolution at all. If you have positioned the 7960 phones on separate subnets (Aux VLANs) then its simple enough to not send DNS server addresses to the phones on that subnet, therefore bypassing the lookup alltogether. Down the road there may be a need to use DNS on the phones as more and more apps are written for them. We initially had problems with our production and test lab call managers, but it was due to option 150 being incorrectly interpreted by the phones (the phones were looking elsewhere in the DHCP data for the 150 information).
5) Once the phone has the Call Manager address it needs to register with Call Manager and download its configuration. It gets primarily these three pieces of information from Call Manager: List of Call Managers (redundancy), Region and Keypad template information - this information is supplied through the SEP*.CNF file and finally the load id (version of code). The phone also downloads the ringlist.dat file which determines what ring types are displayed and accessible to the IP phone.
6) Download new code (load id) this is done the first time the phone boots or is restarted after a code change.
7) Finally the phone registers with Call Manager. Phones can be registered either through auto-discovery or through static configuration.
Hope this helps,
Dennis
