IP Phone Startup Process

Figure 4-4 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). Understanding the boot process of a Cisco IP Phone is critical to your abilities to troubleshoot an IP telephony network.

Figure 4-4. Cisco IP Phone Startup Process

The following list explains the normal boot process of a Cisco IP Phone:

Step 1.	Obtain power from the switch When a Cisco IP Phone is connected to a Cisco Catalyst switch model that is capable of providing inline power (called Power over Ethernet [PoE]), the switch automatically detects an unpowered phone and sends power down the Ethernet cable to the IP Phone. The details of how the switch detects an unpowered IP Phone and how it delivers power to the IP Phone are covered in Chapter 8, "Cisco Catalyst Switches."
Step 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.
Step 3.	Configure the VLAN After the IP Phone receives power and boots, the switch sends a Cisco Discovery Protocol version 2 (CDPv2) trigger packet to the IP Phone. CDP packets that are "triggered" do not need to wait for the default 60-second CDP hello interval. This CDPv2 packet provides the IP Phone with voice VLAN information, if you have configured that feature (voice VLANs are also discussed in Chapter 8). The IP Phone will then tag all its traffic with the appropriate voice VLAN information.
Step 4.	Obtain the 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, the default gateway, and the IP address of the Cisco TFTP server.   Tip A DHCP server can give a Cisco IP Phone the location of a TFTP server in two different ways: DHCP Option 66 Gives the Cisco IP Phone the hostname of the TFTP server (requires DNS resolution)   DHCP Option 150 Gives the Cisco IP Phone the IP address of the TFTP server   The DHCP administrator must add one or both of these options to the DHCP scope used for the Cisco IP Phones. If you cannot use the DHCP server to distribute this information, you must hard code the IP address of the TFTP server manually on each IP Phone. Cisco recommends using DHCP Option 150 because it allows you to configure the IP Phone to use multiple TFTP server addresses for redundancy.
Step 5.	Contact the 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 that 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 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 or .sgn (secured load) file.
Step 6.	Register with Cisco CallManager After obtaining the file from the TFTP server, the phone attempts to make a TCP connection to a Cisco CallManager, starting with the highest-priority Cisco CallManager in its list. After the phone registers with the Cisco CallManager, it receives an extension number and becomes operational.