- "Do I Know This Already?" Quiz
- Foundation Topics: Connecting and Powering Cisco IP Phones
- VLAN Concepts and Configuration
- Understanding the Cisco IP Phone Boot Process
- Configuring a Router-Based DHCP Server
- Setting the Clock of a Cisco Device with NTP
- IP Phone Registration
- Exam Preparation Tasks: Review All the Key Topics
- Definitions of Key Terms
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:
- The phone has received Power over Ethernet (PoE) from the switch.
- The phone has received VLAN information from switch via CDP.
- The phone has received IP information from the DHCP server (including Option 150).
- 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.