IP Phone, SCCP & SIP Phone Registration Process wi

Introduction

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.

SCCP Phone Boot process.bmp

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.

sip boot process.bmp

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.

Recommendation

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.

转载于:https://blog.51cto.com/737110312/2289559