The boot process of an IP phone begins with obtaining power from a Cisco switch and loading a stored firmware image. It then configures its VLAN, obtains an IP address and TFTP server address from a DHCP server. The phone contacts the TFTP server to get configuration files containing CallManager information. Finally, it registers with the highest priority CallManager based on the configuration files.

1. Boot Process of IP Phone
This figure provides an overview of the startup process for a Cisco IP Phone if you are using a Cisco Catalyst switch that is capable
of providing Cisco prestandard Power over Ethernet (PoE).
1. Obtain power from the switch: If you are using a Cisco switch that is capable of providing Cisco inline power, the switch will
send a Fast Link Pulse (FLP) signal. The switch uses the FLP to determine if the attached device is an unpowered Cisco IP
Phone. In the unpowered state, a Cisco IP Phone loops back the FLP, signaling the switch to send -48 V DC power down
the line.
2. Load the stored phone image: The Cisco IP Phone has nonvolatile Flash memory in which it stores firmware images and
user-defined preferences. At startup, the phone runs a bootstrap loader that loads a phone image stored in Flash memory.
Using this image, the phone initializes its software and hardware.
3. Configure VLAN: After the IP Phone receives power and boots up, the switch sends a Cisco Discovery Protocol packet to
the IP Phone. This Cisco Discovery Protocol packet provides the IP Phone with voice VLAN information, if that feature has
been configured.
4. Obtain IP address and TFTP server address: Next, the IP Phone broadcasts a request to a DHCP server. The DHCP server
responds to the IP Phone with a minimum of an IP address, a subnet mask, and the IP address of the Cisco TFTP
5. Contact TFTP server for configuration: The IP Phone then contacts the Cisco TFTP server. The TFTP server has
configuration files (.cnf file format or .cnf.xml) for telephony devices, which define parameters for connecting to Cisco
CallManager. The TFTP server sends the configuration information for that IP Phone, which contains an ordered list of up to
three Cisco CallManagers. In general, any time you make a change in Cisco CallManager that requires a phone (device) to
be reset, a change has been made to the configuration file of that phone. If a phone has an XML-compatible load, it
requests an XMLDefault.cnf.xml format configuration file; otherwise, it requests a .cnf file.
If you have enabled auto-registration in Cisco CallManager, the phones access a default configuration file
(sepdefault.cnf.xml) from the TFTP server. If you have manually entered the phones into the Cisco CallManager database,
the phone accesses a .cnf.xml file that corresponds to its device name. The .cnf.xml file also contains the information that
tells the phone which image load that it should be running. If this image load differs from the one that is currently loaded on
the phone, the phone contacts the TFTP server to request the new image file, which is stored as a .bin file.
6. Register with Cisco CallManager: After obtaining the file from the TFTP server, the phone attempts to make a TCP
connection to the highest-priority Cisco CallManager on the list.