cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
23853
Views
6
Helpful
0
Comments

 

 

Introduction

 

This document discusses how to handle and Troubleshoot common Cisco Unified Communications Manager Express (CME) Registration Issues and provides an approach to solving them. Also this document covers the fundamental approach and process for Troubleshooting any network related issues.

 

 

Prerequisites

  • Working knowledge on Cisco Unified Communication Express (CME).

 

Troubleshooting Methodology for any Network related Issues

 

cme troubleshoot-1.bmp

 

  • If the Problem is not solved, then undo the changes implemented and return to step 3.
  • If the Problem is solved then identify the root cause, document the solution and implement the changes in your network

 

 

Troubleshooting IP Telephony issues requires you to ask probing questions to help narrow down the many possible issues to a focused troubleshooting process.

 

Say for example, "Your IP Phone is not working" and you can use the Troubleshooting process to narrow down the issues.

 

Start Troubleshooting your Network and Cisco Unified Communications Manager Express (CME) related issues in the following order,

 

Step 1: Issues related to the network

 

Step 2: Issues related to the IP Phone Configuration

 

Step 3: Issues related to the CME configuration.

 

 

Understanding IP Phone Boot Process

 

IP Phone boot up.bmp

 

1. The 802.3af Power over Ethernet (POE) switch sends a small DC voltage on the Ethernet cable, detects an unpowered 802.3af device and supplies power to the line.

 

2. The Switch delivers Voice VLAN Information to the Cisco IP Phone using Cisco Discovery Protocol (CDP).

 

3. The IP Phone sends a DHCP request on its Voice VLAN. The DHCP server replies with IP addressing information including the DHCP option 150, which directs the IP Phone to the TFTP server.

 

4. The IP Phone contacts the TFTP server and downloads its configuration file and firmware.

 

5. Based on the IP address listed in the configuration file, the IP Phone contacts the call processing server the CME router which supports the VOIP functionality.

 

Common Issues on CME and Troubleshooting Process

 

Network Related Issue

 

1. Verifying PoE

 

If the IP Phone does not receive Power, nothing is going to work and you can quickly diagnose the issue by asking the user if the IP Phone is displaying anything on the screen and if it is not displaying then you can focus on,

 

1. Physical Connectivity: Check the IP Phone physical connectivity whether the IP Phone is securely plugged in and verify all the patches.

 

2. Check the POE Switch: Ensure the Switch is online and operational.

 

3. Check the IP Phone: Verify that the IP Phone does not have expansion modules causing it to exceed PoE capabilities, move the IP Phone to a different Port to see if it receives power and you can also try a different IP Phone on the same port to diagnose the problem. Ensure the IP Phone and POE switch support a compatible PoE standard (Cisco inline power, 802.3af and 802.3at)

 

2. Voice VLAN Assignment

 

If the IP Phone is assigned to the wrong VLAN then it may not be able to contact the DHCP, CME and TFTP servers. You can diagnose this by,

 

1. Checking the Switch Configuration: Ensure that you correctly configured the voice VLAN by

 

  • Viewing the running-configuration using # show run
  • Verifying the interface operating mode by entering a # show interface <interface name>
  • Verifying the Voice VLAN created on the switch # show vlan
  • Verifying the Voice VLAN is added to all applicable trunk connections # show interface trunk
  • Verifying the CDP is enabled on the port connected to the IP Phone since the voice VLAN is sent to the IP Phone using CDP

 

2. Checking the IP Phone: If you have Physical access to the IP Phone, navigate to the network settings page, Use the Screen settings Button on the phone.

  • Verify that the IP Phone has received the voice VLAN configuration
  • Verify that the IP Phone has IP address and access the Phone IP address in a web browser and view the log files.

 

3. DHCP Server

 

Receiving an IP address through DHCP goes hand-in-hand with the Voice VLAN assignment. If the IP Phone is not assigned to the correct VLAN, it may not receive an IP address from the DHCP server, or if it does, the DHCP options for the pool may not be correct. After you verify the Voice VLAN configuration, you can follow the below steps to troubleshoot the DHCP process,

 

1. Check the DHCP helper-address: If you are using a centralized DHCP server, ensure the router supporting the Voice VLAN is forwarding DHCP requests to a proper server, using # helper-address command under the router interface connected to the VLAN.

 

2. Check the DHCP Server:

  • Verify that the DHCP server has an IP address pool created for the Voice VLAN devices
  • Ensure the Pool is not running out of the IP addresses
  • Verify that DHCP option 150 (TFTP server) is properly configured and assigned to the pool, connect other test devices say PC or Laptop in the voice VLAN and ensure the test devices receives the IP address.

 

3. Check the IP Phone: If you have physical access to the IP Phone, navigate to the network settings page using the "Setting button" on the IP Phone and

 

  • Verify that the IP Phone received an IP address from the appropriate subnet
  • Verify all applicable DHCP options say subnet mask, default gateway, TFTP server are filled in and attempt to ping the phone from another subnet to ensure routing works without any Access control list (ACL) block the network.
  • While diagnosis, try assigning static IP to the IP Phone and see if the phone registers successfully with CME. If it does register successfully then the problem is more likely related to DHCP or VLAN issues. If not the problem is more likely related to routing, TFTP or CME issues.

 

4. TFTP Server

 

The TFTP server is a critical part of the IP Phone boot process because it supplies the phone firmware and configuration file with the base settings the phone should use for operation and the IP address fo the CME server for registration. Although CME supports using an external TFTP server to store all this data, most CME deployments simply use the flash memory and dynamic RAM of the router to store these files. Here's the procedure to troubleshoot TFTP communication.

 

1. Check the routing configuration: If the TFTP server is on a different subnet than the IP Phone, validate whether the data is able to route between the two subnets by placing a test device say PC or laptop in the Voice VLAN and testing connectivity to the TFTP Server by transferring files via TFTP.

 

2. Check the TFTP Server:

  • Verify that the TFTP Server is operational and service files, validate the firmware for the IP Phone model in question exists on the TFTP server as well as a specific configuration file for the Phone.
  • Configuration file should have the MAC address of the IP Phone in the filename
  • Verify that you entered the # create cnf-files command from telephony-service configuration mode to generate the necessary configuration files on the TFTP server.

 

3. Check the IP Phone: If you have physical access to the IP Phone, navigate to the network settings page using the "Setting button" on the IP Phone and

 

  • Verify that the IP Phone is configured either statically or via DHCP for the appropriate TFTP Server IP address.

 

 

5. Cisco Unified Communication Manager Express (CME) Server

 

The final troubleshooting step is to investigate the CME Server itself.

 

The most common CME issue encountered is a "Registration Rejected" error message on the IP Phone. Seeing this error actually gives a clue. It means that the IP Phone is moving through the entire boot process but fails when trying to register with the CME router. Almost 100% of your focus should be on the ephone settings.

 

  • A registration rejected message almost always appears because the IP Phone has not been properly configured in CME.
  • First validate that an ephone entry exists in your CME configuration for the IP Phone.
  • If so, verify that the MAC address entered for the ephone matches the MAC address of the IP Phone.
  • Verify the MAC address directly from the Phone settings or the Cisco Switch, viewing the dynamic MAC address learned on the port connecting to the IP Phone.

 

If getting error message "registration rejected maximum phones exceeded" after upgrade then the possible cause can be missing the the End User License Agreement.

 

 

If the MAC address appears correct in the CME configuration, try enabling the auto-registration in CME, # auto-reg-ephone under the telephony-service configuration. This should allow the phone to register without any extension assignment. You can then validate the MAC address of the IP Phone by entering the # show ephone command.

 

If you want to diagnose, enter # debug ephone detail and you will be able to watch the IP Phone registration process line by line.

 

For more information on configuring the SCCP/SIP Phones with CME to make basic calls refer,

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmebasic.html#wp1043996

 

 

Useful TIP

 

  • It is normal for a newly installed IP Phone to reboot several times because of firmware and configuration updates.
  • First try Restart your IP Phone and see whether the IP Phone registration issue gets rectified. If it doesn't work and before you move in to the troubleshooting process, it's always best to RESET the phone configuration settings to factory default. Resetting the Phone configuration gives you a clean starting ground to work from. Then you can try registering your IP Phone.
  • Be careful while giving # debug ephone detail command, since it might become overwhelming if you have many phones registering at the same time in a large enterprise network.
  • All IP phones of a single phone type failed to successfully register:-

 

          All Cisco Unified IP phones of a particular type can fail to register for one of the following reasons:-

 

     •The wrong or incorrect Cisco phone firmware filename is specified for a particular phone type.

     •The phones cannot download the correct Cisco phone firmware file from the TFTP server.

     •Auto assign for a specified phone type is enabled and there are more phones of that type than there are available telephone or extension numbers.

 

 

 

Related Information

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: