The Cisco IP Phone has a standard startup process consisting of several steps. The steps are illustrated in Figure 7-2 and outlined as follows:
Step 1 PoE: The Cisco IP Phone obtains power from the switch. The switch continuously sends a small voltage on the transmit pins. The voltage sent by the switch is then looped back in hardware from the IP phone back to the switch's receiving pins. The switch has now detected an in-line power-requiring device, and the Cisco switch generates the port's default power allocation. The default power allocation is 10 watts with Cisco proprietary PoE and 15.4 watts with the IEEE 802.3af in-line power specification. Type B Cisco phones support IEEE power and Cisco power, but the IEEE specification did not exist when Cisco manufactured the Type A phones. The 79x2 and 79x5 phones require IEEE or wall power bricks. The Cisco power option does not supply enough power to power these phones.
Step 2 Loading the stored phone image: The Cisco IP Phone has nonvolatile flash memory where the phone's firmware image is stored. At startup, the phone runs a bootstrap loader that loads the phone image from flash memory. Using this image, the phone initializes its software and hardware.
Step 3 Configuring VLAN: A Cisco Catalyst switch uses CDP to inform the Cisco IP Phone which voice VLAN the phone should use for all VoIP traffic. An application-specific integrated circuit (ASIC) in the phone's hardware is used to create Ethernet 802.1q frames before transmitting the traffic on the switch port. The ASIC also gives the phone 1p3q1t (one priority queue, three normal queues, and one drop threshold) QoS capabilities and allows the phone to act like a three-port switch. The Cisco IP Phone does not support the weighted random early detection (WRED) congestion-avoidance protocol. The one threshold is set to tail drop (100 percent queue utilization).
Step 4 Obtaining an IP address: Cisco IP Phones use DHCP by default to obtain an IP address, subnet mask, default gateway, and TFTP server (option 150). The phone sends out a Layer 2 broadcast to the Ethernet layer 2 broadcast address of FF-FF-FF-FF-FF-FF. The DHCP server receives this broadcast and returns an IP address lease from the DHCP scope for the Cisco IP Phones, which contains an IP address, default gateway, subnet mask, and TFTP server (option 150). If DHCP is not used in the network, a static network configuration must be assigned to each IP phone locally. If the DHCP server does not respond, the IP phone will make use of the DHCP scope stored in NVRAM. DHCP information will be in NVRAM only if the phone has previously obtained a lease from the DHCP server.
Step 5 Requesting the configuration file and the profile file: The TFTP server has configuration files. A configuration file includes parameters for connecting to CUCM and information about which image load a phone should be running.
The IP phone first requests its SEP<mac-address>.cnf.xml file from the TFTP server. If the TFTP server does not respond, the IP phone falls back to the last used configuration stored in NVRAM. If the TFTP server responds, but the SEP<mac-address>.cnf.xml file is not found on the server, the phone requests the XMLDefault.cnf.xml file. The XMLDefault.cnf.xml file is used to request an auto-registration configuration. Auto registration is disabled by default. CUCM dynamically generates a directory number and configuration file for the IP phone if auto registration has been provisioned.
If cryptographic features are enabled in CUCM, the phone then attempts to download a certificate trust list (CTL) in addition to the phone configuration file.
Step 6 Registering: The configuration file includes a prioritized list of CUCM servers that are configured in CUCM as a CallManager group. After obtaining the file from the TFTP server, the phone attempts to register with the highest-priority CUCM in the CallManager group using SCCP over TCP port 2000.
Figure 7-2 Cisco IP Phone: SCCP Boot Process
The boot sequences for SIP phones are similar to those used for SCCP phones. There are three main differences:
■ SEP<mac>.cnf.xml: The SIP phones get their entire configuration from the configuration file. The SEP<mac-address>.cnf.xml file is much larger for SIP than for SCCP.
■ Dial plan file (optional): The Cisco SIP phones can download and use local dial plans. Third-party SIP phones can be configured with local dial plans, but they cannot be configured and downloaded from CUCM. Third-party phone configuration takes place on the third-party device.
■ Soft key file: The SIP phones download their soft key sets in an XML soft key file, whereas SCCP phones receive these soft key states as part of the SCCP call-control signaling.
Steps 1 through 4 of the SCCP boot process are identical in both Cisco SIP Phones and Cisco SCCP Phones. The steps in Figure 7-3 follow the step list that follows, but all the steps of Figure 7-2 are also performed by the Cisco SIP Phones. Figure 7-2 illustrates a high-level overview of the network integration of the Cisco IP Phone, and 7-3 illustrates the details of the files and messages exchanged between the IP phone and the TFTP and CUCM servers. The step list that follows assumes the SIP phone has obtained power, the voice VLAN, and a DHCP scope from the DHCP server. Cisco SCCP and SIP Phones have a similar boot and registration process. The primary differences have been highlighted in the three previous bullet points.
Step 1 The SIP phone boots and downloads a CTL file from the TFTP server.
The CTL file contains a set of X.509v3 certificates and is used only when CUCM cluster security has been enabled. Cluster security is covered in Cisco Unified Communications IP Telephony, Part 2.
Step 2 The SIP phone requests its SEP<mac-address>.cnf.xml file from the Cisco TFTP server.
Step 3 If the SIP phone has not been provisioned before boot time, the SIP phone downloads the default configuration file XMLDefault.cnf.xml from the TFTP server. The default configuration file is used only if auto registration has been enabled. Auto registration using SIP requires a file containing a parameter called auto_registration_name. If this parameter is blank, the SIP phone will not auto-register. If this parameter is not blank, the SIP phone will attempt to auto-register.
Step 4 The SIP phone requests a firmware upgrade (Load ID file), if one was specified in the configuration file. This process allows the phone to upgrade the firmware image, allowing it to operate with future versions of CUCM. Each version of CUCM updates the firmware of the Cisco IP Phones so that they can properly communicate with CUCM. After the image has been downloaded and authenticated with the Cisco self-signed X.509v3 certificate, the SIP phone reboots to load the new image. This process might require many reboots to incrementally upgrade the firmware of the IP Phone.
Step 5 The Cisco IP Phone registers with the highest-priority CUCM server. The default SIP configuration file indicates whether the SIP phone should connect using User Datagram Protocol (UDP) port 5060 (default) or TCP. The TCP transport layer IP is supported and configurable on Type B phones only.
Booting for Type B Cisco IP Phones is slightly different from this procedure, which describes the boot sequence of Type A Cisco IP Phones. Type B Cisco IP Phones first download the SIPdefault.cnf file, which contains the default configuration parameters shared by all SIP phones that use the TFTP server. The Cisco SIP Phone continues requesting the SIP<mac>.cnf file to receive its individual configuration file.
Figure 7-3 Cisco IP Phone: SIP Boot Process Cisco SIP Phone Cisco TFTP
Figure 7-3 Cisco IP Phone: SIP Boot Process Cisco SIP Phone Cisco TFTP
Was this article helpful?