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:
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."
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.
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.
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.
A DHCP server can give a Cisco IP Phone the location of a TFTP server in two different ways:
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.
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.
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.
Part I: Cisco CallManager Fundamentals
Introduction to Cisco Unified Communications and Cisco Unified CallManager
Cisco Unified CallManager Clustering and Deployment Options
Cisco Unified CallManager Installation and Upgrades
Part II: IPT Devices and Users
Cisco IP Phones and Other User Devices
Configuring Cisco Unified CallManager to Support IP Phones
Cisco IP Telephony Users
Cisco Bulk Administration Tool
Part III: IPT Network Integration and Route Plan
Cisco Catalyst Switches
Configuring Cisco Gateways and Trunks
Cisco Unified CallManager Route Plan Basics
Cisco Unified CallManager Advanced Route Plans
Configuring Hunt Groups and Call Coverage
Implementing Telephony Call Restrictions and Control
Implementing Multiple-Site Deployments
Part IV: VoIP Features
Configuring User Features, Part 1
Configuring User Features, Part 2
Configuring Cisco Unified CallManager Attendant Console
Configuring Cisco IP Manager Assistant
Part V: IPT Security
Securing the Windows Operating System
Securing Cisco Unified CallManager Administration
Preventing Toll Fraud
Hardening the IP Phone
Understanding Cryptographic Fundamentals
Understanding the Public Key Infrastructure
Understanding Cisco IP Telephony Authentication and Encryption Fundamentals
Configuring Cisco IP Telephony Authentication and Encryption
Part VI: IP Video
Introducing IP Video Telephony
Configuring Cisco VT Advantage
Part VII: IPT Management
Introducing Database Tools and Cisco Unified CallManager Serviceability
Configuring Alarms and Traces
Using Additional Management and Monitoring Tools
Part VIII: Appendix
Appendix A. Answers to Review Questions