Cisco IP Phone Boot Process (SCCP & SIP)

1-Protocols

1.1-TFTP

TFTP is a critical service for IP Phones. The Phone use TFTP to download their configuration files, firmware and other data. Without TFTP, the phones simply do not function properly. When you make a configuration change to a device, CUCM creates or modifies a config file for the device and uploads it to the TFTP server. TFTP service much therefore provided by one or more CUCM servers in the cluster.

Note: A generic TFTP server will not have the integrated capability that a CUCM TFTP server does and will not correctly fulfill the role

1.2-DHCP

Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that automatically provides an Internet Protocol (IP) host with its IP address and other related configuration information such as the subnet mask and default gateway. RFCs 2131 and 2132 define DHCP as an Internet Engineering Task Force (IETF) standard based on Bootstrap Protocol (BOOTP), a protocol with which DHCP shares many implementation details. DHCP allows hosts to obtain necessary TCP/IP configuration information from a DHCP server.

Every device on a TCP/IP-based network must have a unique unicast IP address to access the network and its resources. Without DHCP, IP addresses must be configured manually for new computers or computers that are moved from one subnet to another, and manually reclaimed for computers that are removed from the network.

1.3-CDP

Cisco Discovery Protocol is primarily used to obtain protocol addresses of neighboring devices and discover the platform of those devices. CDP can also be used to display information about the interfaces your router uses. CDP is media- and protocol-independent, and runs on all Cisco-manufactured equipment including routers, bridges, access servers, and switches.

CDP messages are generated every 60 seconds as multicast messages on each of its active interfaces. The information shared in a CDP packet about a Cisco device includes the following:

Name of the device configured with the hostname command
IOS software version
Hardware capabilities, such as routing, switching, and/or bridging
Hardware platform, such as 2600, 2950, or 1900
The layer-3 address(es) of the device
The interface the CDP update was generated on

CDP allows devices to share basic configuration information without even configuring any protocol specific information and is enabled by default on all interfaces. CDP is a Data Link Protocol occurring at Layer 2 of the OSI model. CDP is not routable and can only go over to directly connected devices.

Cisco Discovery Protocols Configuration commands

Router#show cdp

//Displays global CDP information (such as timers)

Router#show cdp neighbors

//Displays information about neighbors

Router#show cdp neighbors detail

//Displays more detail about the neighbor device

Router(config)#cdp holdtime x

//Changes the length of time to keep CDP packets

Router(config)#cdp timer x

//Changes how often CDP updates are sent

Router(config)#cdp run

//Enables CDP globally (on by default)

Router(config)#no cdp run

//Turns off CDP globally

Router(config-if)#cdp enable

//Enables CDP on a specific interface

Router(config-if)#cdp enable

//Enables CDP on a specific interface

Router(config-if)#no cdp enable

//Turns off CDP on a specific interface

Router#debug cdp adjacency

//Monitors CDP neighbor information

Router#debug cdp events

//Monitors all CDP events

Router#debug cdp ip

//Monitors CDP events specifically for IP

Router#debug cdp packets

Monitors CDP packet-related information

2-Concept of Boot Steps:

1-) The PoE switch (using standard 802.3af or Cisco inline power mechanism) will detect that there is an unpowered IP device (PD) connected to its port and go ahead and provide power to the IP phone. The phone will then boot-up its firmware image.

2-) The switch will provide the Voice VLAN information to the phone using CDP (Cisco Discovery Protocol) or possibly standards based LLDP (Link Layer Discovery Protocol). This will inform the IP phone what VLAN it belongs to for sending voice traffic.

3-)The IP phone will now send a DHCP request within the Voice VLAN. It will receive its IP address, subnet mask, default gateway and the CUCM TFTP server IP address (via DHCP option 150)

4-) The IP phone will contact the TFTP server to retrieve its configuration (.cnf). Thisconfiguration file is provide based on the requesting IP phone’s MAC address. This configuration file (among other things) will include the ordered list of CUCM servers whichthe phone should attempt to register to (i.e. primary,secondry,tertiary CUCM servers)

5-) The IP phone will now contact its primary CUCM server listed within its retrieved configuration file. It will register and become available for use.

2.1-SCCP Phone Registration Process

SCCP phone obtains the Power (PoE or AC adapter).
The phone loads its locally stored firmware image.
The phone learns the Voice VLAN ID via CDP from the switch.
The phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address.
The phone contacts the TFTP server and requests its configuration file. Each phone has a customized configuration file named SEP<mac_address>.cnf.xml created by CUCM and uploaded to TFTP when the administrator creates or modifies the phone.
The phone registers with the primary CUCM server listed in its configuration file. CUCM then sends the softkey template to the phone using SCCP messages.

What is in that SEP<mac_address>.cnf.xml file ?

This file contains a list of CUCM server, in order, that the phone should register with. It lists teh TCP ports it should use for SCCP communication. It also lists the firmware version for each device model and the service URLs that each device should be using.

The CUCM server sends other configurations such as DNs, softkeys and speed dials via the SCCP messages in the last phase of the registration process.

2.2-SIP Phone Registration Process

SIP Phones use a different set of steps to achieve the same goal. Steps 1 to 4 are the same as SCCP Phones, refer the steps as illustrated in the figure: SCCP Phone Boot Process .

The phone contacts the TFTP server and requests the Certificate Trust List file (only if the cluster is secured).
The phone contacts the TFTP server and requests its SEP<mac-address>.cnf.xml configuration file.
If the SIP Phone has not been provisioned before boot time, the SIP Phone downloads the default configuration XMLDefault.cnf.xml file from the TFTP server.
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 automatically when required for a new version of CUCM.
The phone downloads the SIP dial rules configured for that phone.
The phone Establish connection with the primary CUCM and the TFTP server end to end.
The phone Registers with the primary CUCM server listed in its configuration file.
The phone downloads the appropriate localization files from TFTP
The phone downloads the softkey configurations from TFTP
The phone downloads custom ringtones (if any) from TFTP.