This document covers the IP Phone Registration Process with the Cisco Unified Communications Manager (CUCM). It covers both SCCP and SIP Phone Registration Process to help the beginners to understand the basics of IP Phone boot process better which will help in Configuration and Troubleshooting the Network related issues easily.
IP Phone Registration Process
SCCP Phone Registration Process
1. SCCP phone obtains the Power (PoE or AC adapter).
2. The phone loads its locally stored firmware image.
3. The phone learns the Voice VLAN ID via CDP from the switch.
4. The phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address.
5. 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.
6. 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.
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 .
1. The phone contacts the TFTP server and requests the Certificate Trust List file (only if the cluster is secured).
2. The phone contacts the TFTP server and requests its SEP<mac-address>.cnf.xml configuration file.
3. 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.
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 automatically when required for a new version of CUCM.
5. The phone downloads the SIP dial rules configured for that phone.
6. The phone Establish connection with the primary CUCM and the TFTP server end to end.
7. The phone Registers with the primary CUCM server listed in its configuration file.
8. The phone downloads the appropriate localization files from TFTP.
9. The phone downloads the softkey configurations from TFTP.
10. The phone downloads custom ringtones (if any) from TFTP.
About TFTP server:
TFTP is a critical service for IP Phones. The Phone use TFTP to download their config 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.
Take note of the place where the files are logged. Cisco CallManager 3.x and 4.x, by default, stores trace files in the C:\Program Files\Cisco\Trace\CCM\ directory, but these files can be specified to be stored elsewhere in the trace configuration. Other services log their traces in their respective directories. As mentioned earlier, in Versions 5.x/6.x/7.x, they are stored in the location that the RTMT specifies.
Browse in the Windows Explorer to the trace directory in order to collect the correct trace files. Then choose View > Details from the menu bar in order to view dates and times. Make the window large enough to see these values.
Note: If you reproduce a problem, make sure to select the file for the timeframe when you reproduced it. Look at the modification date and the timestamps in the file. The best way to collect the right traces is to reproduce a problem, quickly locate the most recent file, and copy it from Cisco CallManager.
Files are overwritten after some period of time. In order to find the current file that is logged, click View > Refresh on the menu bar and look at the dates and times on the files. You can view and configure the location, size, and lifespan of the trace files, as shown in the preceding diagram.
Traces can be CPU intensive for the Cisco CallManager server. It is a good practice to turn off traces after you have collected them. Follow the same procedure used to enable the traces, but uncheck the "Trace On" settings and save.
Video: Add IP Phones to Cisco Unified Communications Manager 7.x and later
This video explains the step by step procedure to quickly add a Cisco IP phone to Cisco Unified Communications Manager 7.x and later.
NIM-4FXS on ISR4351 running IOS XE 16.6.6 (CME 12.0) Please note port 0/2/0 is off-hook while STCAPP status is idle instead of off-hook. The same used to work fine on 2900/3900 series routers. CG1#sh voice port summaryIN OUTPORT CH SI...
Our DX80 is connected to the corp network, we use for video conf and also to display screen contents via HDMI connection to a laptop. When both are in progress, the call controls constantly flash as if the screen was being constantly touched, so oft...
Hi all,I see CUCM voice ports as the calling DN in RTMT trace logs. I am trying to understand how a CUCM voice port can be the calling DN of an outbound external call? I don't see any Call handlers that are transferring calls to external number...
I am attempting to write some scripts in C# that will take advantage of the UCCE 11.6 Rest API. In particular, I am looking to do bulk agent creation. I am able to successfully connect to the remote server where UCCE lives, but when I try to se...