Before you can create ephones, you need to define how many ephones will be allowed to register to the Cisco Unified CME. While the hardware platform determines the maximum number of phones that the hardware can support, you might not want that many phones to register to the Cisco Unified CME. The router reserves memory based on the number of phones it is configured to support. By default, the maximum is set to 0. The command used to set the maximum number of ephones is

For example, if you want to configure the Cisco Unified CME to allow 15 phones to register, you would enter max-ephones 15. This command must be issued from telephony-service configuration. You can enter telephony-service configuration by entering telephony-service from the global configuration prompt.

After you define the maximum number of ephones, you can create ephones. Creation of an ephone is done from the global configuration mode on the Cisco Unified CME router. The command to create an ephone is as follows:

The phone-tag parameter is a number that is used to identify this ephone. A phone-tag can be any number you choose, but each ephone must have a unique phone-tag. To create an ephone using 10 as the phone tag, you would enter ephone 10.

Using the ephone phone-tag command creates an ephone. However, that alone does not allow a phone to register. After you create the ephone, you must configure it. After an ephone is created, the prompt changes to show that you are in ephone configuration. The prompt looks something like the following:

From this prompt, you can define various parameters of the ephone. You first must define the MAC address of the phone and the DN(s) that will be assigned to the phone. To define the MAC address, enter the mac-address command followed by the MAC address. The MAC address must be in the proper format. As you know, a MAC address is 12 hexadecimal characters long. The format used to assign one to an ephone is four sets of four hexadecimal characters. The following is an example for defining the MAC address of 00CC0001A1231ABF to ephone:

To assign a DN to the phone, you must first create an ephone-dn. The next section covers how to create and assign ephone-dns.

An ephone-dn represents a line that can be assigned to an ephone to allow a voice channel. An ephone-dn can have one or more numbers assigned to it. Just think of an ephone-dn as being equal to a line on a phone.

The configuration of an ephone-dn is fairly simple, but before you create one, you should define the maximum number of DNs that you want the Cisco Unified CME to allow to register. By default, this is set to 0. This is similar to how you had to define the maximum number of ephones that could register. The command is max-dn number, where number is the number of DNs the router is to support. To configure the router to support 24 DNs, you would issue the following command at telephony-service configuration:

To create an ephone-dn, two commands must be entered. First, use the following command to create the ephone-dn:

The dn-tag parameter is a number that is used to identify this ephone-dn. It is not a directory number. It is only used to identify the ephone-dn. A dn-tag can be any number you choose, but each ephone-dn must have a unique dn-tag. To create an ephone-dn using 101 as the dn-tag, you would enter ephone-dn 101.

Next you need to define the directory number that will be associated with this ephone-dn. This is done using the number command. After you create an ephone-dn, you will be in ephone-dn configuration mode.

The following commands show how to create an ephone-dn with a dn-tag of 101 and a directory number of 2001:

Now that you know how to create a basic ephone-dn, let’s take a look at how it is assigned to an ephone. To enter the configuration mode for an ephone, you issue the same command you did when you first created the ephone, which is ephone phone-tag. If the ephone exists, you will enter the configuration mode for it; if it doesn’t, the ephone will be created and you will enter the configuration mode for it. After you are in ephone configuration mode, you assign an ephone-dn to a button on the phone by using the button command. The syntax for the button command is button button-number{separator}dn-tag. For example, to assign the ephone-dn 101 to the second button on the phone, you would enter button 2:101. This command does not assign the extension number 101 to the second button. It assigns the extension number that is associated with ephone-dn 101. Let’s take a look at a complete example of creating a phone with the following characteristics:

Listing 10.1 includes the router prompts so that you can see what config mode the commands are entered in.

To better understand each of these commands, take a look at Table 10.1, which lists each command and offers a brief explanation.

Table 10.1 Example Configuration of an Ephone

As you know, the button command defines what ephone-dn is assigned to a button on the phone. But it does more than that: It also defines how the ephone-dn is assigned. How an ephone is assigned to a button impacts how it will function. In the command button 1:101 the colon (:) is referred to as a separator. The separator is used to define how the button will function. There are nine different separators. So far, we have only looked at the colon, which configures the line to act normally, that is, to ring normally and function in much the way you would expect a phone line to function. The following is a list of the other operators that can be used and a brief explanation for each one:

Let’s take a look at a couple of examples. If you were to configure a button as follows, the ephone-dn 101 would be assigned to the first button on the phone, and when a call came in on that line, it would not ring. But, if a person were already on a call when a new call arrived, the person would hear the call waiting beep:

If a button were configured as follows, ephone-dn 101 would be assigned to the fourth button and would be used to monitor the status on the extension assigned to ephone-dn 101. This line could not be used to place or receive calls:

You should now understand how to create basic ephones and ephone-dns and associate ephone-dns to buttons. Up to now, we have been discussing basic single-line ephone-dns. Ephone-dns can be configured to function in a number of different manners. The following sections explore six types of ephone-dns:

The following sections describe the commands to configure telephony service parameters.

Phones require the correct firmware to register to and work with Cisco Unified CME. There are specific firmware files for each model of Cisco IP phone. The phone retrieves these files through TFTP. TFTP must be configured on the Cisco Unified CME to allow the serving of the required firmware files. The tftp-server command is done in global config mode. The tftp-server command is used to determine which files are going to be available. The command syntax follows:

The flash keyword specifies that the file is in flash. The filename parameter is the name of the file that needs to be served. Because some Cisco IP phone models need multiple files, the tftp-server command needs to be issued a number of times.

Consider the Cisco Unified IP Phone 7961G running SCCP, for example. Listing 10.8 shows the commands that need to be entered to make all the required firmware files available. Keep in mind that the names of the firmware files change based on the version of Cisco Unified CME.

The total number of files that need to be made available depends on the number of different phone models you are using. Also, if phones are using Session Initiation Protocol (SIP) instead of SCCP, different firmware files are required, which could increase the total number of files being served.

Making the firmware files available through TFTP is only half the job of configuring Cisco Unified CME to serve the files for the phones. The other step that is required is to define what firmware file each phone model should request. This needs to be done because, as upgrades are made, new firmware files are released, and there needs to be a way to tell the phone which file it should be using. The load command is used for this.

The syntax for the load command is load followed by the model of the phone and the name of the firmware file. For example, the load command for a 7941 phone would look something like the following:

You execute this command from telephony-service configuration mode. Only one firmware file is associated with each phone model. When a phone needs more than one firmware file, such as in the case of the Cisco 7961G, the firmware file that has a .loads extension is used. If more than one firmware file ends with .loads, use the one that begins with SCCP (or SIP if running SIP). For example, the command to associate the correct firmware file to a Cisco 7961G is load 7961 SCCP41.8-3-3S. Notice that you do not include the .loads extension in the command. When specifying the model phone in the load command, make sure that you use the correct syntax. The following is a list of valid model names for the load command:

Before registering phones, you need to run the create cnf-files command. When a phone registers, it requests a configuration file. The create cnf-files command creates these files for SCCP phones. It creates these files based on the current configuration. It creates a configuration file for each phone that is configured in the system.

Using everything you have learned so far, you can configure Cisco Unified CME so that phones can register and make calls. This, however, would require you to add every phone individually, and while adding a phone is not difficult, having to add 100 could be quite time consuming. One way to speed up the process is to allow phones to autoregister. This is done by using the auto-reg-ephone command. This command is entered in telephony-service configuration mode. After the command is entered, phones are allowed to register, even if an ephone has not been configured for them. To disable autoregistration, issue the no auto-reg-ephone command. When autoregistration is disabled, Cisco Unified CME records any MAC address that attempts to register. You can view these MAC addresses by using the show ephone attempted-registration command.

To assign an ephone-dn to a phone that autoregisters, you must use the auto assign command. This command defines which ephone-dns will be assigned to phones as they register. You define a range of ephone-dns, and they are assigned on a first come, first served basis. You can also define which types (models) of phones are assigned an ephone-dn from a given range. For example, you could have Cisco 7960 Phones assigned ephone-dns 101–150 and Cisco 7971 Phones assigned ephone-dns 54–100. The auto assign command also allows you to define what number a call will be routed to if the ephone-dn is busy or not answered. The following command assigns ephone-dns 101–145 to 7961 phones and forwards busy calls or calls that go unanswered for 10 seconds to extension 2001:

In this example, the values that are highlighted are the variables that you define. You see that 101 to 145 are the ephone-dns that will be assigned to the 7961 type of phone. The call forward (cfw) is set to 2001, and the timeout for ringing is set to 10 seconds.

There are a few caveats that you should be aware of when using the auto assign command:

After all required configuration is complete, you should be able to plug phones in and they should register. Of course, the operative word here is should. From time to time, something can occur that causes phones to fail to register. This section covers common issues and describes how you can verify that the endpoint registered. All the commands discussed in this section are issued from global configuration mode.

First, you should verify that the VLAN and IP configuration in the phone are correct. The VLAN and IP configuration can be viewed on the phone’s screen by pressing the Settings button and selecting Network Configuration. If the IP address settings are not correct, check the DHCP configuration.

If the DHCP configuration is correct and the phone is not registering, check to see whether the firmware files are in the flash on the Cisco Unified CME and whether the load commands are in the configuration and correct.

Next, check to see what files the phone is requesting. This is done by using the debug tftp events command. This command displays the files that the TFTP server is sending; this includes the firmware, XML configuration, and locale files.

You can then use the debug ephone register command to see the registration process. After issuing this command, reset the phone and watch the registration process. You should look for the Load= parameter. On this line, you should see what firmware file and version it is loading.

You can use the show ephone command to see which phones have successfully registered. This command also shows some configuration information, such as the ephone-dn assigned to the buttons. You can also see the current status, such as whether the phone is ringing or off-hook.

To verify that locale files are being used, issue the show telephony-service tftp-bindings command. This command displays all configuration files that are available to phones through TFTP, which includes the user-locale and network-locale.

And, of course, we can’t forget the arguably most used command, show running-config. This command shows the configuration of the router. Many configuration errors are often found by simply spending a little time looking at the running-config.

From time to time, you might need to reboot a phone. This is required after updating certain configuration information or while troubleshooting. There are two commands used to reboot a phone: reset and restart. The reset command is the more drastic of the two. Reset is similar to powering the phone off and on. This is the type of reboot that would be used when the firmware, user-locale, network-locale, and URL parameters change.

The restart command is like soft reboot. This is useful for changes to phone button, phone line, and speed dial number. The restart command does not cause the phone to go through the DHCP and TFTP process, so it is faster than reset.