IP Phone Registration

Now that the Cisco IP Phone has gone through the complete process, it is ready to register

with the call-management system (CME or CUCM). Before we discuss this final step, keep

in mind what the phone has gone through up to this point:

1. The phone has received Power over Ethernet (PoE) from the switch.

2. The phone has received VLAN information from switch via CDP.

3. The phone has received IP information from the DHCP server (including Option 150).

4. The phone has downloaded its configuration file from the TFTP server.

The Cisco IP Phone is now looking at a list of up to three call processing servers (depending

on how many you have configured) that it found in the configuration file it retrieved

from the TFTP server. The phone tries to register with the first call processing server. If

that fails, it continues down the list it received from the TFTP server until the phone

makes it through all the listed call processing servers (at which point it reboots if it finds

no servers online).

If the IP phone finds an active server in the list, it goes through the registration process using

either the Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP).

The protocol the phone uses depends on the firmware it is using. Today, most Cisco IP

Phones use the SCCP, which is Cisco proprietary. However, as the SIP protocol matures,

widespread support continues to grow. Because SIP is an industry standard, using it across

your network provides benefits such as vendor neutrality and inter-vendor operation.

Regardless of the protocol used, the registration process is simple: The Cisco IP Phone

contacts the call processing server and identifies itself by its MAC address. The call processing

server looks at its database and sends the operating configuration to the phone.

The operating configuration is different than the settings found in the configuration XML

file located on the TFTP server. The TFTP server configuration is “base level settings,” including

items such as device language, firmware version, call processing server IP addresses,

port numbers, and so on. The operating configuration contains items such as

directory/line numbers, ring tones, softkey layout (on-screen buttons), and so on. Although

the TFTP server configuration is sent using the TFTP protocol, the operating configuration

is sent using SIP or SCCP.

These protocols (SIP or SCCP) are then used for the vast majority of the phone functionality

following the registration. For example, as soon as a user picks up the handset of the

phone, it sends a SCCP or SIP message to the call processing server indicating an off-hook

condition. The server quickly replies with a SCCP or SIP message to play dial tone and

collect digits. As the user dials, digits are transmitted to the call processing server using

SCCP or SIP; call progress tones, such as ringback or busy, are delivered from the call processing

server to the phone using SCCP or SIP. Hopefully, you get the idea: The Cisco IP

Phone and call processing server have a dumb terminal and mainframe style of relationship,

and the “language of love” between them is SCCP or SIP.

Task 1: Configure Communications Manager System Parameters

In this Task we will prepare Cisco Unified Communications Manager for IP Phones for 2 Sites. For Chicago (Site 2) the Branch Site we will manually add Phones.

Activity Procedure

Complete these steps:

1. From Communications Manager Administration page, go to System > Cisco Unified CM Group.
2. On the Find and List Unified CM Group page, click Find button to list all Communications Manager Groups that have been configured on the system. If this is a new installation, there will be one Communications Manager Group called Default.
3. Click on Communications Manager Group Default to change its configuration.
4. On Cisco Unified Communications Manager group configuration page, if this is a new installation by default only the publisher server is selected as member for the Cisco Unified Communications Manager group default. Since there is only one Communications Manager is this topology there will not be any servers listed in the available servers list.
5. The first item on Selected Cisco Unified Communications Managers will become the active call processing engine for this Communications Manager group.
6. Click Save button to save any changes on the system and click Ok to restart all active devices assign with this Communications Manager group.
7. On the Cisco Unified Communications Manager Administration page, from the menu select System > Device Pool.
8. On Find and list Device pools page, click Find button to list all device pools configured on the system.
9. If this is a new installation, only one device pools called default is on the list.
10. To add new device pool, click Add new button.
11. Create a new device pool with the following parameters:
    - Device Pool Name: Chicago
    - Cisco Unified Communications Manager group: Default
    - Date and time group: CMLocal
    - Region: default
    - SRST Reference: disable
12. Click Save to store the new device pools configuration
13. Repeat step 10 – 12 for another device pools with the following parameters, but do not add a new device pool. Modify the existing device pool Default with the following parameters:
    - Device Pool Name: SanJose
    - Cisco Unified Communications Manager group: Default
    - Date and time group: CMLocal
    - Region: default
    - SRST Reference: disable
14. Confirm that the cluster have two device pools - SanJose and Chicago.