Understand SIP IP Phone Registration Process in CUCM

Available Languages

Download Options

PDF (373.5 KB)
View with Adobe Reader on a variety of devices
ePub (439.8 KB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (209.5 KB)
View on Kindle device or Kindle app on multiple devices

Updated:July 27, 2023

Document ID:220669

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Background information

Requirements

Registration Process

TFTP

Registration process summary

Introduction

This document describes the steps to registering a SIP IP phone in the Unified Communications Manager.

Prerequisites

Cisco recommends that you have basic knowledge of these topics:

Cisco Unified Communications Manager (CUCM or Cisco Call Manager)
Domain Name System (DNS)
Cisco Discovery Protocol (CDP)
Dynamic Host Configuration Protocol(DHCP)
Trivial File Transfer Protocol (TFTP)
Virtual LAN (Voice VLAN)
Power Over Ethernet (PoE)

Background information

An IP phone that has voice functionality needs to be given its configuration and voice functionalities in order to make a call. Without configuration, the phone is just a shell. In order to configure the IP Phone, you must both start and finish the registration in the Cisco Unified Communications Manager (CUCM or Cisco Call Manager).

The phone registration process through the SIP protocol changes a little compared to the SCCP (Skinny) protoco. However, that is out of the scope of this document.

Requirements

Have added the device in Call Manager, filled in at least the required configuration and added at least 1 line.

Registration Process

The IP phone is connected via PoE (power over ethernet) or AC adapter to obtain power.
The phone loads its locally stored firmware image. Some IP phones have a Flash memory in which they store their default firmware image containing their software and user-defined preferences. Upon starts, the phone runs a boot loader that loads an image of the phone stored in Flash memory. Using this image, the phone initializes its software and hardware.
The phone learns the Voice VLAN ID via CDP from the switch. The switch sends a Cisco Discovery Protocol packet to the IP phone. This Cisco Discovery Protocol packet provides the phone with information about the voice VLAN, if such a function has been configured. The voice VLAN is a VLAN that is specifically assigned to users voice data streams.
The phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address (via option 150). The IP phone broadcasts a request to a DHCP server. The DHCP server performs its address lookup process according to the configured address pool and verifies the configured options, performs DORA (Discover, Offer, Request, Acknowledge) process, and responds to the phone with the found addresses.

Note: DHCP option 150 supports a list of TFTP servers (Multiple Server IPs). DHCP option 66 only supports the IP address or the hostname of a single TFTP server.
The phone contacts the TFTP server and requests the Certificate Trust List file (CTL) file, TFTP provides the CTL file only if the cluster is secured (Mixed mode), in case non-secure mode, it is expected to receive a "404 not found" error message from TFTP.

GHTTP-http get [HTTP/1.1 404 Not Found^M Conten]
The phone contacts the TFTP server and requests the Identity Trust List (ITL) file.
The phone contacts the TFTP server and requests the SEP<mac-address>.cnf.xml configuration file, which contains parameters for the IP Phone such as call manager group, IP address, port, time zone, and others.

Note: 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 verify if a firmware upgrade is needed if a specific firmware image is in the configuration file. This process allows the phone to upgrade the firmware image automatically when required.
The phone downloads the SIP dial rules configured for that phone.
The phone establish connection with the primary CUCM. After obtaining these files from the TFTP server, the phone attempts to make a TCP connection to the highest-priority Cisco CallManager on the list on the Call Manager Group.
The phone Registers with the primary CUCM server listed in the configuration file. IP Phone sends a SIP REGISTER message to CUCM to request the registration and CUCM answers with a 200 OK to the REGISTRER message.
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.

The IP phone does not display a registered message, but the IP of the phone with the active and inactive load ids is displayed on the page of the phone in CUCM. When the phone shows the Directory number, the phone was successfully registered.

Device Registration Status

Phone Registration Display 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 configuration file for the device and uploads it to the TFTP server. TFTP service could be provided by one or more CUCM servers in the cluster.

Registration process summary

SIP IP Phone Registration Process

Logs

Different components are involved in the phone registration process as CUCM, TFTP, DHCP, Switch, IP Phone. In order to verify if those components perform the steps correctly, it can be validated in their logs.