Cisco IP Phones: Boot Sequence Best CCNP Training Institute in New Delhi Gurgaon

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

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).
152 Chapter 7: Endpoints
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.
Cisco IP Phones: Boot Sequence 153
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.
V
IP
DHCP CUCM Cisco TFTP
2
3
4 5
6
1
154 Chapter 7: Endpoints
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.