Troubleshooting Phone Registration

This section examines the phone's behavior during registration, describes common problems encountered during registration, and illustrates the tools you use to troubleshoot these problems.

The IP phone registration process is fundamental to solving many problems encountered during initial Cisco CME setup. A good understanding of the phone bootup and registration process, phone display messages, and relevant debugs can help you troubleshoot most of these types of problems.

Understanding the Phone Bootup Sequence

When powered on, a phone goes through various states before it attempts to register with a Cisco CME. This section provides an overview in which you learn the correct behavior of an IP phone when it boots up and registers with Cisco CME. The next section provides a step-by-step explanation of the states the phone goes through and what the messages on the phone display mean. The section "Debugging VLAN, DHCP, TFTP, and Registration Issues" discusses problems and issues that may arise when phones don't register correctly.

The following steps summarize the phone bootup sequence; the rest of this section describes the process in more detail:

When powered on, an IP phone issues a CDP request to discover its VLAN information from the LAN switch. It then broadcasts a DHCP request to obtain an IP address. An IP phone's default operation is to broadcast for DHCP. If you want to, you can manually disable this operation.

You can configure a DHCP server on the LAN or across the WAN at another site. The DHCP server responds to the DHCP request with the IP address, default gateway, and TFTP server information if configured. It is recommended that the TFTP server be the Cisco CME router. Upon receiving its IP information, the IP phone downloads a file named SEPxxxxyyyyzzzz.cnf.xml, where xxxxyyyyzzzz denotes the IP phone's MAC address from the TFTP server. Some of the important information contained in this file includes

• IP address of the Cisco CME router
• Phone load
• Network locale
• User locale

Example 16-1 shows a sample phone configuration file.

Example 16-1. Contents of the SEPDefault.cnf.xml File

2000 10.1.0.3 {7960 Dec 23 2004 14:43:07} English_United_States en United_States 0 http://10.1.0.3:80/localdirectory

At this point, the phone has enough information to register with the Cisco CME router, and it sends a registration request. The Cisco CME router verifies the phone's configuration against the router's running configuration. If it is correct, the phone registration succeeds. An exception to this registration sequence is when an upgrade of the phone load is required. When the IP phone downloads the SEPxxxxyyyyzzzz.cnf.xml file from the router during the registration process, the phone compares the load mentioned in this file with the load already installed. If these differ, the phone tries to upgrade its firmware before it sends the registration request to the Cisco CME router. This is explained in the following sections.

Understanding the Messages on the Phone Display

The display on the phone is a very useful tool in debugging problems encountered during phone registration. A unique message is shown on the phone display for each step in the registration process. With correct configurations in place, a phone registration takes between 60 and 180 seconds to complete. Some of the key messages explained in the following sections are

• Configuring VLAN
• Configuring IP
• Configuring CM
• Registering
• Cisco CME
• Upgrading Firmware (if necessary)

Before each of these messages is described in more detail, the next section explains what to do when no message appears on the screen.

No Message Appears on the Phone Display

No message on the phone display means that the phone isn't powered. Therefore, it must be plugged into a power outlet or an Ethernet-powered LAN port. As soon as it is powered on and plugged into a LAN switch's Ethernet port, the phone immediately starts booting. The three LED buttons on the bottom right of the phonethe speakerphone, mute, and headset buttonslight in sequence for a period of 1 or 2 seconds. This indicates that the phone is getting power. A blank display a few seconds after power-on means that the phone's Ethernet connection is not fully functional. The following are some of the possible problems that might cause this situation:

• The Ethernet cable is plugged into the wrong Ethernet port for the phone. The cable should be plugged into the first Ethernet port.
• The LAN switch port is administratively shut down.
• You are using the wrong cable, or the cable is not plugged in properly. Hence, the connector's pins are not making proper contact with the phone or switch port.
• The switch port does not support inline power; an external phone power supply is required.

The "Configuring VLAN" Message

If the physical and data-link layers on the Ethernet connection are operational, the phone multicasts Cisco Discovery Protocol (CDP) packets on the LAN. The phone shows the "Configuring VLAN" message on its display for a short time during this process. If the LAN switch is configured with the appropriate voice VLAN configuration, it responds to the CDP query from the phone, and the phone configures itself accordingly.

If the phone is connected to a device that does not support CDP, the CDP query times out, and the phone moves on to the next step in the registration sequence. Therefore, even if the LAN switch is not configured with voice VLAN information, the phone should still get registered.

The "Configuring IP" Message

The next step in the phone registration process is configuring Layer 3 parameters such as the IP address and default gateway the phone should use. To achieve this, the phone broadcasts a DHCP request on the LAN. The message on the phone display changes to "Configuring IP."

Phones shipped from the Cisco factory are configured to obtain Layer 3 parameters via DHCP. If the "Configuring VLAN" message was previously displayed on the phone, you should now see the "Configuring IP" message.

Note

You can also manually configure Layer 3 parameters on the phone by turning off the DHCP feature.

The "Configuring IP" message alone doesn't guarantee that the phone's Layer 3 configuration is correct. If configured properly, the phone acquires its Layer 3 parameters and moves on to the next step in the registration process. If this doesn't happen because of an incorrect configuration, the phone continues to display the "Configuring IP" message indefinitely. This stage of the registration should not take more than approximately 60 seconds. If your phone display appears stuck at the "Configuring IP" message for longer than this, inspect the DHCP configuration on the router.

Simply obtaining an IP address and related parameters doesn't mean that the configuration is correct. An incorrect subnet mask or a wrong TFTP server IP address can prevent the phone from successfully registering with the Cisco CME router. It is a good practice to always check the configurations on the phone. This saves time by helping you identify potential problems faster.

After the phone has obtained its correct Layer 3 parameters, it is a fully functional IP endpoint. The next step in the registration sequence is to download the SEPxxxxyyyyzzzz.cnf.xml file to obtain the Cisco CME IP address and other related parameters. Incorrect configurations can cause this file to have the wrong information, which prevents the phone from registering or operating correctly. Not executing the create-cnf command keeps the file from being present on the system, so the phone can never register properly.

The "Configuring CM" Message

If the XML configuration file is present on the router and the phone downloads it successfully via TFTP, the phone display changes to "Configuring CM." At this point, the phone has the IP address of its call controller and the information necessary to register with it.

The "Registering" and "Cisco CME" Messages

The phone sends a registration request to the Cisco CME router. If the Cisco CME router is configured correctly, a successful registration takes place.

During the registration process, the message on the phone display changes to "Registering." Upon successful registration, you should see "Cisco CME" displayed on the phone, with the extension number(s) assigned next to the appropriate buttons. An exception to this is if a phone firmware upgrade is required.

The "Upgrading Firmware" Message

If a phone firmware upgrade is required during the registration process, the phone downloads the new firmware from the Cisco CME router before registering with Cisco CME. After the phone downloads the SEPxxxxyyyyzzzz.cnf.xml file, the display on the phone changes to "Upgrading Firmware." The phone goes through the bootup sequence again after downloading the new firmware.

Understanding SCCP Endpoint Registration

Figure 16-1 shows the message exchange involved in registering an Skinny Client Control Protocol (SCCP) IP phone with Cisco CME. You can see most of the registration messages by turning on debug ephone register during phone registration. To view all the registration messages, turn on debug ephone detail in addition to debug ephone register.

Figure 16-1. SCCP Phone Registration Sequence

Sample output of a debug ephone register command is shown in Example 16-2. These debugs can be useful in troubleshooting registration as well as other problems.

Example 16-2. Output of debug ephone register

Router#debug ephone register Mar 1 02:53:11.327: ephone-(1)[1] StationRegisterMessage (0/0/24) from 10.1.1.101 *Mar 1 02:53:11.327: ephone-(1)[1] Register StationIdentifier DeviceName SEP000DBDBEF372 *Mar 1 02:53:11.327: ephone-(1)[1] StationIdentifier Instance 1 deviceType 7 *Mar 1 02:53:11.327: ephone-1[-1]:stationIpAddr 10.1.1.101 *Mar 1 02:53:11.327: ephone-1[-1]:maxStreams 0 *Mar 1 02:53:11.327: ephone-1[-1]:phone-size 616 dn-size 208 *Mar 1 02:53:11.327: ephone-(1) Allow any Skinny Server IP address 10.1.1.1 *Mar 1 02:53:11.327: ephone-1 *Mar 1 02:53:11.327: Skinny Local IP address = 10.1.1.1 on port 2000 *Mar 1 02:53:11.327: Skinny Phone IP address = 10.1.1.101 51664 *Mar 1 02:53:11.327: ephone-1[1]:RegisterAck sent to ephone 1: keepalive period 30 *Mar 1 02:53:11.327: ephone-1[1]:CapabilitiesReq sent *Mar 1 02:53:11.327: ephone-1[1]:Skinny IP port 53449 set for socket [1] *Mar 1 02:53:11.579: ephone-1[1]:CapabilitiesRes received *Mar 1 02:53:11.579: ephone-1[1]:Caps list 7 G711Ulaw64k 40 ms G711Alaw64k 40 ms G729 60 ms G729AnnexA 60 ms G729AnnexB 60 ms G729AnnexAwAnnexB 60 ms Unrecognized Media Type 25 120 ms *Mar 1 02:53:11.579: ephone-1[1]:ButtonTemplateReqMessage *Mar 1 02:53:11.579: ephone-1[1]:CheckAutoReg *Mar 1 02:53:11.579: ephone-1[1]:AutoReg skipped: phone already has DN 1 *Mar 1 02:53:11.579: ephone-1[1]:Setting 6 lines 0 speed-dials on phone (max_line 6) *Mar 1 02:53:11.579: ephone-1[1]:First Speed Dial Button location is 0 (0) *Mar 1 02:53:11.579: ephone-1[1]:Configured 0 speed dial buttons *Mar 1 02:53:11.579: ephone-1[1]:ButtonTemplate lines=6 speed=0 buttons=6 offset=0 *Mar 1 02:53:11.831: ephone-1[1]:StationSoftKeyTemplateReqMessage *Mar 1 02:53:11.831: ephone-1[1]:StationSoftKeyTemplateResMessage *Mar 1 02:53:12.083: ephone-1[1]:StationSoftKeySetReqMessage *Mar 1 02:53:12.083: ephone-1[1]:StationSoftKeySetResMessage *Mar 1 02:53:12.335: ephone-1[1]:StationLineStatReqMessage from ephone line 6 *Mar 1 02:53:12.335: ephone-1[1]:StationLineStatReqMessage from ephone line 6 Invalid DN -1 *Mar 1 02:53:12.335: ephone-1[1]:StationLineStatResMessage sent to ephone (1 of 6) *Mar 1 02:53:12.587: ephone-1[1]:StationLineStatReqMessage from ephone line 5 *Mar 1 02:53:12.587: ephone-1[1]:StationLineStatReqMessage from ephone line 5 Invalid DN -1 *Mar 1 02:53:12.587: ephone-1[1]:StationLineStatResMessage sent to ephone (2 of 6) *Mar 1 02:53:12.839: ephone-1[1]:StationLineStatReqMessage from ephone line 4 *Mar 1 02:53:12.839: ephone-1[1]:StationLineStatReqMessage from ephone line 4 Invalid DN -1 *Mar 1 02:53:12.839: ephone-1[1]:StationLineStatResMessage sent to ephone (3 of 6) *Mar 1 02:53:13.091: ephone-1[1]:StationLineStatReqMessage from ephone line 3 *Mar 1 02:53:13.091: ephone-1[1]:StationLineStatReqMessage from ephone line 3 Invalid DN -1 *Mar 1 02:53:13.091: ephone-1[1]:StationLineStatResMessage sent to ephone (4 of 6) *Mar 1 02:53:13.343: ephone-1[1]:StationLineStatReqMessage from ephone line 2 *Mar 1 02:53:13.343: ephone-1[1]:StationLineStatReqMessage from ephone line 2 Invalid DN -1 *Mar 1 02:53:13.343: ephone-1[1]:StationLineStatResMessage sent to ephone (5 of 6) *Mar 1 02:53:13.595: ephone-1[1]:StationLineStatReqMessage from ephone line 1 *Mar 1 02:53:13.595: ephone-1[1]:StationLineStatReqMessage ephone line 1 DN 1 = 1001 no desc *Mar 1 02:53:13.595: ephone-1[1]:StationLineStatResMessage sent to ephone (6 of 6) *Mar 1 02:53:13.595: ephone-1[1]:SkinnyCompleteRegistration

Debugging VLAN, DHCP, TFTP, and Registration Issues

An incorrect VLAN, DHCP, TFTP, or Cisco CME (telephony-service) configuration can prevent the IP phones from registering with Cisco CME. Before you troubleshoot any other configuration issues, however, you must fix physical layer problems, as described in the next section.

Physical Layer Problems

Troubleshooting network problems generally starts at the lower layers of the OSI reference model. This same principle holds true for an IP phone, because it is a fully functional IP endpoint. Therefore, it is important to make sure that your physical layer is intact before attempting to troubleshoot problems at higher layers.

Some of the common physical layer problems are as follows:

• The phone doesn't get powered.
• The phone gets powered but doesn't go through the bootup sequence.

These problems can be caused by one of the following:

• The LAN switch port to which the phone is connected is shut down.
• The LAN switch or switch module does not support inline power.
• A faulty or wrong cable is used.
• The cable is connected to the wrong port on the IP phone.

It's easy to see when a phone isn't getting power. If the phone is not getting powered on, chances are good that the LAN switch is not providing or cannot provide inline power. The first thing to do is check that your LAN switch supports inline power for IP phones. If the switch supports inline power but the phone is not getting power, the cause could be a faulty cable, a shut-down port, a cable connected to the wrong IP phone port, or a faulty phone or port (which is rare). You can isolate the problem by doing one or more of the following:

• Plug the phone into a different port to isolate a faulty port.
• Plug a different phone into the same port to isolate a faulty phone.
• Plug a known working phone into the same port to isolate a faulty phone.
• Plug a phone into a known working port to isolate a faulty port.
• Use a cable known to be good.

The preceding actions should eliminate faulty hardware. If the problem persists, the cause might be a configuration issue. Make sure that the LAN switch port is not shut down, and check the configuration to see if inline power is disabled.

Example 16-3 shows a configuration in which switchport fa0/1 is in a shutdown state, inline power is disabled for switchport fa0/2, and switchport fa0/3 is the only port correctly providing inline power to an attached IP phone.

Example 16-3. Switchports with the Wrong Configuration

Switch#show running-config Building configuration... Current configuration: ! version 12.0 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption service internal ! hostname Aprilia_Switch ! no logging console ip subnet-zero ! interface FastEthernet0/1 shutdown switchport access vlan 100 switchport voice vlan 110 ! interface FastEthernet0/2 switchport access vlan 100 switchport voice vlan 110 power inline never ! interface FastEthernet0/3 switchport access vlan 100 switchport voice vlan 110

VLAN

If the physical layer is intact, the phone should be getting power and should start booting up. The next thing to look for is any possible issues related to VLAN. A wrong VLAN configuration prevents the phone from getting its DHCP information or causes it to get the wrong DHCP configuration.

When the phone boots up, it sends three CDP messages requesting the voice VLAN information. If CDP is disabled on the LAN switch or on a particular interface, the phone cannot get its voice VLAN information. If you have configured a voice VLAN for your network, make sure that CDP is also enabled on the router or at least on the ports that are configured for the voice VLAN. Also, make sure that your VLAN configurations are correct.

DHCP

With step-by-step instructions for troubleshooting Cisco CME, DHCP configuration is the next item on the list after VLAN-related problems. A faulty DHCP configuration prevents the phone from having IP connectivity with other equipment on the LAN. Although the DHCP server can be on the LAN or across the WAN, only issues related to DHCP configuration on a LAN are covered here because this is the typical configuration. You can find more information about configuring a DHCP remotely at Cisco.com. Some of the key areas for troubleshooting DHCP are as follows:

• Subnet mask The subnet mask in the DHCP configuration and the one in the network interface should match.
• MAC address The MAC address should be prefixed with 01.
• TFTP server address The TFTP server IP address should be configured. It is also important that there is IP connectivity to the TFTP server.

Example 16-4 shows an extract of a router configuration for DHCP. The Cisco CME router is configured to be the DHCP server for the phones. At first glance the configuration seems fine, but if you look at the phone's network configuration, you can see that the phone has not received an IP address, subnet mask, or TFTP server address.

Example 16-4. Erroneous DHCP Configuration

Router#show running-config Building configuration... ! ip dhcp pool Phone2 host 10.0.0.10 255.0.0.0 client-identifier 0007.8513.136c default-router 10.0.0.1 option 150 ip 10.0.0.1 ! interface Ethernet0/0 ip address 10.0.0.1 255.0.0.0 half-duplex

You can verify an IP phone's network configuration by pressing the settings phone button and selecting the Network configuration option from the menu. You can turn on debug ip dhcp server packets to see the DHCP messages to understand why the phone is not receiving its IP network configuration.

Example 16-5 shows the output of debug ip dhcp server packets. A close look at the configuration and the debugs reveal that the MAC address configured on the router and the MAC address of the IP phone broadcasting the DHCP request are not the same. As a result, the phone is unable to get an IP address via DHCP. If you take a closer look at the MAC address shown in Example 16-4 and the debug output shown in Example 16-5, you can see that the MAC address in the debug output contains two extra digits. In fact, the MAC address in the show output is the MAC address in the configuration prefixed with 01.

Example 16-5. Output of debug ip dhcp server packets with the Wrong MAC Address Configured

CME_Router#debug ip dhcp server packets *Mar 1 00:24:46.459: DHCPD: DHCPDISCOVER received from client 0100.0785.1313.6c on interface Ethernet0/0. *Mar 1 00:24:54.459: DHCPD: DHCPDISCOVER received from client 0100.0785.1313.6c on interface Ethernet0/0.

When configuring the client-identifier (MAC address) for IP phones, you should prefix the actual phone's MAC address with 01. The correct configuration is shown in Example 16-6.

Example 16-6. Correct DHCP Configuration

Router#show running-config Building configuration... ! ip dhcp pool Phone2 host 10.0.0.10 255.0.0.0 client-identifier 0100.0785.1313.6c default-router 10.0.0.1 option 150 ip 10.0.0.1 ! interface Ethernet0/0 ip address 10.0.0.1 255.0.0.0 half-duplex

Example 16-7 shows the debugs with a correct configuration. Comparing the debug text in Example 16-6 with that shown in Example 16-7, you can see that the router is not responding to the DHCP request, because it doesn't have an IP address assigned for the MAC address.

Example 16-7. Output of debug ip dhcp server for a Working Configuration

CME_Router#debug ip dhcp server *Mar 1 05:06:35.074: DHCPD: DHCPDISCOVER received from client 0100.0785.1313.6c on interface Ethernet0/0. *Mar 1 05:06:35.074: DHCPD: Sending DHCPOFFER to client 0100.0785.1313.6c (10.0.0.10). *Mar 1 05:06:35.074: DHCPD: broadcasting BOOTREPLY to client 0007.8513.136c. *Mar 1 05:06:35.078: DHCPD: DHCPREQUEST received from client 0100.0785.1313.6c. *Mar 1 05:06:35.078: DHCPD: Sending DHCPACK to client 0100.0785.1313.6c (10.0.0.10). *Mar 1 05:06:35.078: DHCPD: broadcasting BOOTREPLY to client 0007.8513.136c.

The network configuration menu on the phone is one of the ways you can verify that the phone is getting the right configuration. You can view the IP address, subnet mask, TFTP server address, and Cisco CME IP address from this menu.

You can also erase the current phone configuration, and disable the DHCP option from the same menu. If a user reports that a phone is not working and debugging shows that there is no DHCP broadcast from the phone, it is likely that the DHCP option was accidentally or intentionally disabled from the Network Configuration menu. In the configuration shown in Example 16-4, the DHCP server assigns an IP address based on the phone's MAC address. Another way of configuring DHCP is to have an open pool of address space. This method potentially eliminates the missing 01 prefix problem described previously, but the disadvantage is that the router responds to a DHCP request from any IP endpoint on the network.

TFTP

The phone uses TFTP to download files required during the registration process, such as the following:

• SEPxxxxyyyyzzzz.cnf.xml file
• Phone firmware (if an upgrade or downgrade is necessary)
• Network and user locale files
• Language files

All these files are created and stored in the Cisco CME system memory when you issue the create-cnf files command. An exception to this is the phone firmware, which must be copied onto flash and placed on the TFTP server using the command tftp-server flash:filename. You can see the files on the system memory by issuing the command show telephony-service tftp-bindings. A sample output of this command is shown in Example 16-8. You can see that individual SEPxxxxyyyyzzzz.cnf.xml files are an alias of the XMLDefault7960.cnf.xml file.

Example 16-8. Output of show telephony-service tftp-bindings

CME_HQ#show telephony-service tftp-bindings tftp-server system:/its/SEPDEFAULT.cnf tftp-server system:/its/SEPDEFAULT.cnf alias SEPDefault.cnf tftp-server system:/its/XMLDefault.cnf.xml alias XMLDefault.cnf.xml tftp-server system:/its/ATADefault.cnf.xml tftp-server system:/its/XMLDefault7960.cnf.xml alias SEP000DBDBEF372.cnf.xml tftp-server system:/its/united_states/7960-tones.xml alias United_States/ 7960-tones.xml tftp-server system:/its/united_states/7960-font.xml alias English_United_States/ 7960-font.xml tftp-server system:/its/united_states/7960-dictionary.xml alias English_United_States/7960-dictionary.xml tftp-server system:/its/united_states/7960-kate.xml alias English_United_States/ 7960-kate.xml tftp-server system:/its/united_states/Skinny-dictionary.xml alias English_United_States/Skinny-dictionary.xml

Registration can fail if these files are either unavailable or not placed on the router's TFTP server. Understanding TFTP debug commands is very useful in troubleshooting these problems. One of the most useful TFTP debug commands is debug tftp events. Example 16-9 shows the output of debug tftp events during a successful phone registration. From the debugs you can see that the phone is looking for various files and obtains these files via TFTP.

Example 16-9. Output of debug tftp events During a Successful Registration

CME_HQ#debug tftp events *Jul 20 15:17:50.785: TFTP: Looking for OS79XX.TXT *Jul 20 15:17:50.785: TFTP: Looking for SEP000DBDBEF372.cnf.xml *Jul 20 15:17:50.785: TFTP: Opened system:/its/XMLDefault7960.cnf.xml, fd 0, size 775 for process 131 *Jul 20 15:17:50.789: TFTP: Finished system:/its/XMLDefault7960.cnf.xml, time 00:00:00 for process 131 *Jul 20 15:17:55.813: TFTP: Looking for P00303020200.bin *Jul 20 15:17:58.129: TFTP: Looking for SEP000DBDBEF372.cnf.xml *Jul 20 15:17:58.129: TFTP: Opened system:/its/XMLDefault7960.cnf.xml, fd 0, size 775 for process 131 *Jul 20 15:17:58.133: TFTP: Finished system:/its/XMLDefault7960.cnf.xml, time 00:00:00 for process 131

Registration Problems

In this section, you learn how to interpret the output of the show ephone command, and then tackle a phone registration problem. Example 16-10 shows the output of the relevant portion of the running configuration of a Cisco CME router.

Example 16-10. Configuring the CME Router

CME_HQ#show running-config ip dhcp pool phoneA host 10.10.10.141 255.255.255.0 client-identifier 0100.07eb.4629.9e default-router 10.10.10.1 option 150 ip 10.10.10.1 ! ip dhcp pool phoneB host 10.10.10.142 255.255.255.0 client-identifier 0100.03e3.7376.fb option 150 ip 10.10.10.1 default-router 10.10.10.1 telephony-service load 7910 P00403030401 load 7960-7940 P00303020214 max-ephones 24 max-dn 24 ip source-address 10.10.10.1 port 2000 create cnf-files version-stamp Jan 01 2002 00:00:00 max-conferences 8 ! ephone-dn 1 dual-line number 1001 huntstop channel ! ephone-dn 2 number 1002 name CS Engineer2 ! ephone-dn 5 number 1005 name CS Engineer5 ! ephone 1 mac-address 0007.EB46.299E type 7960 button 1:1 2:2 ! ephone 2 mac-address 0003.E373.76FB button 1:2

Example 16-11 gives the show ephone output for the same configuration. The output provides a lot of useful information about the phone's current state. This information includes the phone's MAC address, IP address, and whether the phone is registered.

Example 16-11. Output of show ephone

CSE_HQ#show ephone ephone-1 Mac:0007.EB46.299E TCP socket:[4] activeLine:0 REGISTERED mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.141 49654 Telecaster 7960 keepalive 1 max_line 6 button 1: dn 1 number 1001 CH1 IDLE CH2 IDLE button 2: dn 2 number 1002 CH1 IDLE shared ephone-6 Mac:0003.E373.76FB TCP socket:[3] activeLine:0 REGISTERED mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.142 52023 Telecaster 7960 keepalive 1 max_line 6 button 1: dn 2 number 1002 CH1 IDLE shared

One important point to note from the configuration shown in Example 16-10, and the show ephone output shown in Example 16-11, is the ephone tag (the number next to ephone). The tag for the ephone with MAC address 0007.EB46.299E (ephone 1) is the same in the configuration and the show ephone output, but the tag for the ephone with MAC address 0003.E373.76FB (ephone-2) is different. The tag for the second ephone is 6 in the show ephone output and 2 in the configuration. This is very important when troubleshooting, because if you look for the phone by its configuration tag, chances are you are looking at the wrong phone. You should always look up the phone by MAC address in the show output.

The last two lines of the ephone 1 output (the lines starting with button) tell you which ephone-dns are attached to the ephone.

For ephone 1, button 1 is attached to ephone-dn 1 (button 1: dn 1, 1001) and button 2 is attached to ephone-dn 2 (button 2: dn 2, 1002). In the case of the ephone-dn, the tag shown on the show output and the configuration are the same as that in the configuration (unlike the tags for the ephones). The extension numbers configured for the ephone-dn are also shown in this output. Another useful piece of information available on the same line is the status of the virtual voice port attached to this ephone-dn.

Ephone-dn 1 is a dual-line DN and, hence, has two channels (CH1 and CH2 in Example 16-11) associated to the same voice port. Ephone-dn 2 is a single-line DN and, hence, has only a single channel (CH1) associated with it. All the voice channels shown in Example 16-11 are in the IDLE state, which means that the phones are on-hook. Some of the other channel states you may see include

• SEIZED (off-hook)
• RINGING
• HOLD

You can also see from Example 16-11 that ephone 1 and ephone 2 share the same ephone-dn 2 (extension 1002) on buttons 2 and 1 of the phones, respectively.

The second lines of the debug for each ephone in Example 16-11 show the parameters mediaActive, offhook, ringing, reset, and others with a 0 or 1 next to them. A 0 next to the parameter means no, and 1 means yes. For example, offhook: 1 means that the phone is off-hook. Similarly, ringing: 0 means that the phone is not ringing. These extra details make troubleshooting Cisco CME much easier.

At this point, a new phone is added to the existing configuration, and the relevant portion of the new configuration is shown in Example 16-12.

Example 16-12. CME Configuration After a New Phone Is Added

CME_HQ#show running-config ip dhcp pool phoneA host 10.10.10.141 255.255.255.0 client-identifier 0100.07eb.4629.9e default-router 10.10.10.1 option 150 ip 10.10.10.1 ! ip dhcp pool phoneB host 10.10.10.142 255.255.255.0 client-identifier 0100.03e3.7376.fb option 150 ip 10.10.10.1 default-router 10.10.10.1 ip dhcp pool phoneC host 10.10.10.143 255.255.255.0 client-identifier 0100.0dbd.bef3.72 default-router 10.10.10.1 option 150 ip 10.10.10.1 telephony-service load 7910 P00403030401 load 7960-7940 P00303020214 max-ephones 24 max-dn 24 ip source-address 10.10.10.1 port 2000 create cnf-files version-stamp Jan 01 2002 00:00:00 max-conferences 8 ! ephone-dn 1 dual-line number 1001 huntstop channel ! ephone-dn 2 number 1002 name CS Engineer2 ! ephone-dn 3 number 1003 name CS Engineer3 ! ephone-dn 4 number 1004 name CS Engineer4 ! ephone-dn 5 number 1005 name CS Engineer5 ! ephone 1 mac-address 0007.EB46.299E type 7960 button 1:1 2:2 ! ephone 2 mac-address 0003.E373.76FB button 1:2 ! ephone 3 mac-address 000B.BDBE.F372 type 7910 button 1:4

The show ephone output for the same configuration is shown in Example 16-13.

Example 16-13. Output of show ephone After a New Phone Is Added

CME_HQ#show ephone ephone-1 Mac:0007.EB46.299E TCP socket:[2] activeLine:0 REGISTERED mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.141 52800 Telecaster 7960 keepalive 25 max_line 6 button 1: dn 1 number 1001 CH1 IDLE CH2 IDLE button 2: dn 2 number 1002 CH1 IDLE shared ephone-6 Mac:0003.E373.76FB TCP socket:[1] activeLine:0 REGISTERED mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.142 51595 Telecaster 7960 keepalive 26 max_line 6 button 1: dn 2 number 1002 CH1 IDLE shared ephone-3 Mac:000B.BDBE.F372 TCP socket:[-1] activeLine:0 UNREGISTERED mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.143 52243 Unknown 0 keepalive 0 max_line 0 ephone-4 Mac:000D.BDBE.F372 TCP socket:[3] activeLine:0 REGISTERED mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.143 50898 Telecaster 7960 keepalive 23 max_line 6

A quick look at the configuration indicates that only three phones are configured, but four phones show up in the show ephone output. When the debugs were done, only three phones were plugged into the network, so where did the fourth phone come from?

You can also see from the output shown in Example 16-13 that three of the four phones are in REGISTERED state but the fourth one is in UNREGISTERED state. The ephone with tag 3 (in Example 16-13) is in UNREGISTERED state. This phone also doesn't have a line number next to its buttons, so you cannot make a call from this phone. This problem is caused by having entered an incorrect MAC address.

The actual MAC address of ephone-3 is 000D.BDBE.F372. If you look at the configuration, however, you can see that the fourth digit is wrong (B instead of D). This is the reason why ephone-3 (in Example 16-13) is in the UNREGISTERED statebecause such a phone does not exist in the configuration used for this example. If a phone with such a MAC address doesn't exist, it cannot register with the router, so that accounts for ephone-3 being in UNREGISTERED state. Now if you look at the MAC address of ephone-4 (in Example 16-13), it matches the correct MAC address.

The phone is registered even though it was never configured. Cisco CME lets a phone register by default as long as the phone is a supported model, and the system has not exceeded its max-ephone limit. However, even though the phone is in REGISTERED state, you can see that no lines are assigned to the ephone (compare it to the output of ephone 1 and ephone 6 in Example 16-13). The reason is that no line was assigned to the phone (with the correct MAC address) in the configuration. This explains the missing line number on the physical phone.

If you try to fix the problem by entering the correct MAC address for ephone 3, the router doesn't accept it. Instead, it displays an error message, as shown in Example 16-14.

Example 16-14. Error Output When the MAC Address Is Changed

CME_HQ(config)#ephone 3 CME_HQ(config-ephone)#mac-address 000d.bdbe.f372 ePhone slot is already registered with 000b.bdbe.f372. Can not change MAC address. CME_HQ(config-ephone)#

From the router's perspective, you are trying to assign ephone 3 (in the configuration as well as the show output) the MAC address of ephone 4 (in the show output), which is already in REGISTERED state. Therefore, this is unacceptable.

The solution for this problem is to remove ephone 3 from the configuration, and add ephone 4 with the correct MAC address, as shown in Example 16-15.

Example 16-15. Correcting the Faulty MAC Address

CME_HQ(config-ephone)#no ephone 3 CME_HQ(config)#ephone 4 CME_HQ(config-ephone)#mac-address 000D.BDBE.F372 CME_HQ(config-ephone)#button 1:3 CME_HQ(config-ephone)#restart

Missing create-cnf file Command

A missing create-cnf command can be another reason why the phone does not register successfully with the Cisco CME router. As covered earlier, in the section "Understanding the Phone Bootup Sequence," you can see that the phone gets the Cisco CME router's IP address from the SEPxxxxyyyyzzzz.cnf.xml file and that this file is, in turn, created by the command create-cnf. Thus, if the command is not part of the configuration, the SEPxxxxyyyyzzzz.cnf.xml file is not created. Therefore, the phone cannot download it from the router. Actually, the file is created even if you don't issue the create-cnf file command, but the file is not populated. So technically, an empty SEPxxxxyyyyzzzz.cnf.xml file is in the system memory.

In addition to the SEPxxxxyyyyzzzz.cnf.xml file created by the create-cnf file command, this command creates the files necessary for the user locale and network locale. The user locale defines the language used by the phone on its display. The network locale defines the values for call progress tones for various geographic regions of the world. By default, the user locale and network locale are set to U.S. (United States).

The display on the phone is the most visible indication of a problem with the files created by the create-cnf file command: The phone's display switches between "Configuring IP" and "Configuring CM." If you scroll through the Network Configuration menu, you can see that the Call Manager field is not populated.

An exception to this display behavior is if the phone was registered to another Cisco CME system in the past. In this case, the phone still has its previous CME address populated in the Call Manager field, even if it cannot download a valid SEPxxxxyyyyzzzz.cnf.xml file from the current system. This happens because the phone remembers the last Cisco CME it was successfully registered with.

You can view the files created using create-cnf file by using the command show telephony-service tftp-bindings. Also, you can view the file contents by issuing the more command followed by the filename with a path to the location.

Example 16-16 shows the output of the show telephony-service tftp-bindings command for a configuration without the create-cnf file command. You can see that the output shown in Example 16-16 does not have the localization files. Also, the output of more system:/its/XMLDefault7960.cnf.xml returns nothing, which means that the file is empty.

Example 16-16. show Output Without the create-cnf-file Command

CME_HQ#show telephony-service tftp-bindings tftp-server system:/its/SEPDEFAULT.cnf tftp-server system:/its/SEPDEFAULT.cnf alias SEPDefault.cnf tftp-server system:/its/XMLDefault7960.cnf.xml alias SEP000DBDBEF372.cnf.xml CME_HQ# CME_HQ#more system:/its/XMLDefault7960.cnf.xml CME_HQ#

Example 16-17 shows the output of the show telephony-service tftp-bindings command, which indicates that all the necessary files are present on the system. Also, the file has all the necessary information required for the phone to register.

Example 16-17. show Output with the create-cnf-file Command Present

CME_HQ#show telephony-service tftp-bindings tftp-server system:/its/SEPDEFAULT.cnf tftp-server system:/its/SEPDEFAULT.cnf alias SEPDefault.cnf tftp-server system:/its/XMLDefault7960.cnf.xml alias SEP000DBDBEF372.cnf.xml tftp-server system:/its/XMLDefault.cnf.xml alias XMLDefault.cnf.xml tftp-server system:/its/ATADefault.cnf.xml tftp-server system:/its/united_states/7960-tones.xml alias United_States/ 7960-tones.xml tftp-server system:/its/united_states/7960-font.xml alias English_United_States/ 7960-font.xml tftp-server system:/its/united_states/7960-dictionary.xml alias English_United_States/7960-dictionary.xml tftp-server system:/its/united_states/7960-kate.xml alias English_United_States/ 7960-kate.xml tftp-server system:/its/united_states/Skinny-dictionary.xml alias English_United_States/Skinny-dictionary.xml CME_HQ#more system:/its/XMLDefault7960.cnf.xml 2000 10.1.1.1 {Jan 01 2002 00:00:00} P00303020214 English_United_States en United_States 0 http://10.1.1.1:80/localdirectory

If you turn on debug tftp events on the Cisco CME router, you can see that the phone repeatedly tries to download the SEPxxxxyyyyzzzz.cnf.xml file via TFTP. Because the file is empty without create-cnf file configured, even though it downloads the file, the phone can't get the necessary Cisco CME IP address to register with, and it attempts to download the file again. This is shown in Example 16-18.

Example 16-18. Output of debug tftp events Without the create-cnf file Command

CME_HQ#debug tftp events TFTP Event debugging is on CME_HQ# *Jul 23 11:05:04.399: TFTP: Looking for OS79XX.TXT *Jul 23 11:05:04.399: TFTP: Looking for SEP000DBDBEF372.cnf.xml *Jul 23 11:05:04.399: TFTP: Opened system:/its/XMLDefault7960.cnf.xml, fd 0, size 0 for process 172 *Jul 23 11:05:04.399: TFTP: Finished system:/its/XMLDefault7960.cnf.xml, time 00:00:00 for process 172 CME_HQ# *Jul 23 11:05:07.219: TFTP: Looking for OS79XX.TXT *Jul 23 11:05:07.219: TFTP: Looking for SEP000DBDBEF372.cnf.xml *Jul 23 11:05:07.219: TFTP: Opened system:/its/XMLDefault7960.cnf.xml, fd 0, size 0 for process 172 *Jul 23 11:05:07.219: TFTP: Finished system:/its/XMLDefault7960.cnf.xml, time 00:00:00 for process 172 CME_HQ#

Upgrading IP Phone Firmware

The load command specifies the firmware for each type of phone supported on the system. It is important to distinguish between this load file and the SEPxxxxyyyyzzzz.cnf.xml file. The file referred to in the load command is the firmware load used by each type of IP phone, such as the Cisco 7940 or 7960. On the other hand, the SEPxxxxyyyyzzzz.cnf.xml file is a unique system-generated file for each phone configured on the system.

Factory-shipped IP phones have a default firmware load installed. The firmware load required for each release of Cisco CME is different. It is possible that your IP phones were shipped with firmware that is incompatible with the version of Cisco CME on your router. Refer to the Cisco.com documentation for the correct version of IP phone firmware for the version of Cisco CME you are using. (Go to the Software Center, choose Voice Software, Cisco CallManager Express, and the release of Cisco CME you are interested in, and then look for the document "Specifications for All Versions of Cisco CallManager Express.")

When the IP phone downloads the SEPxxxxyyyyzzzz.cnf.xml file from the router during the registration process, the phone compares the load mentioned in this file with the load already installed in it. If these differ, the phone tries to upgrade its firmware by downloading the new file from the TFTP server, which in this scenario is the Cisco CME router. Therefore, for this firmware upgrade operation to be successful, the new phone load mentioned in the Cisco CME configuration must be present on the TFTP server given in the DHCP configuration.

Note

The firmware change can be an upgrade or a downgrade, depending on the load installed on the phone. If you are upgrading to a signed load, you cannot change your phone load afterward to an unsigned phone load again. Similarly, if the phone already has a signed phone load installed, you cannot downgrade your phone load to an unsigned load; you have to remain on a signed load.

This section discusses upgrading the firmware mentioned in Example 16-8 to a new firmware load named P00303020214.bin. The sample configuration shown in Example 16-19 shows the relevant portions of the modified configuration.

Example 16-19. Configuration for Upgrading the Phone Firmware

CME_Router#show running-config Building configuration... ! ip dhcp pool Phone2 host 10.0.0.10 255.0.0.0 client-identifier 0007.8513.136c default-router 10.0.0.1 option 150 ip 10.0.0.1 ! interface Ethernet0/0 ip address 10.0.0.1 255.0.0.0 half-duplex Telephony-service ip source-address 10.0.0.1 max-dn 10 max-ephone 10 load 7940-60 P00303020214.bin create cnf-files CME_Router#show flash P00303020214.bin

The output from the show flash command in Example 16-19 shows that the new firmware is available on the router flash memory. If the phone is reset, you expect the phone to upgrade its firmware to the new firmware mentioned in the configuration, but when doing this operation, you see the error message "File not found" on the phone display. With Cisco CME 3.0 and later versions, the phone is registered with the error message "Error verifying configuration." In this situation, even though the phone is registered, the correct feature operation is not guaranteed because of the error.

The problem giving rise to these errors is that even though the new firmware has been copied to the router's flash memory, it is still unavailable from the TFTP server. The command tftp-server flash:load_name must be configured (using configuration mode) on the router to make these flash-based files available to the TFTP server. This is a basic Cisco IOS command that is not specific to Cisco CME.

Upgrading Phone Loads to a Signed Load

With Cisco CME 3.1 and later, the Cisco 7960, 7940, and 7910 IP Phones support signed phone loads. The unsigned loads come with a .bin extension file, and the signed load carries an .sbn extension. A phone with an unsigned load always looks for a file with a .bin extension when it tries to download a phone load. This prevents the phone from upgrading from an unsigned phone load with a .bin extension to a signed phone load with an .sbn extension.

Note

A signed phone load allows the phone to support additional security features.

To get around this problem for every version of a signed load, two files are available: one with a .bin extension and another with an .sbn extension. The .bin extension file is actually the signed load (the .sbn) with a wrapper around it so that the phone reads it as a .bin file. To upgrade a phone from an unsigned load to a signed load, the Cisco CME router should have both .bin and .sbn files for the new load. The phone downloads the file with the .bin extension, but it actually gets the signed load.

This is necessary only if you are upgrading from an unsigned load to a signed load. If the phone is already using a signed load, it automatically looks for the file with the .sbn extension when it downloads a new load.

Note

After the phone installs a signed load, it can never be downgraded to an unsigned load again. It is possible to upgrade or downgrade to any other signed load, but not to an unsigned load.