CUCM Initial Configuration

After you install CUCM, some initial configuration has to be done before starting to deploy endpoints. This initial configuration includes the items in Table 5-1.

Table 5-1 Publisher Server Required Services

Configuration Item


Network settings

Basic network settings have already been configured during installation, but some of them should be revisited (use of external NTP and DNS servers), and network settings that are not configurable during installation (for example, enabling DHCP services on CUCM) have to be addressed before endpoint deployment.

Network and feature services

CUCM servers run network services (automatically activated) and feature services (activated by the administrator). After installation, network services should be checked, and desired feature services have to be activated.

Enterprise parameters

CUCM has cluster-wide configuration settings called enterprise parameters. After installation, enterprise parameter default values should be verified and modified if required.

Service parameters

CUCM services have configurable parameters that can usually be set per CUCM server. After installation and service activation, service parameter default values should be verified and modified if required.

Network Components

CUCM leverages various IP networking protocols and systems.

Network Time Protocol

Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over IP networks through use of a hierarchical clock strata organization. A stratum level 1 timing source device is an extremely precise clock source using the rare earth element cesium. Cesium clocks used to be very expensive, but most service providers with large central offices now have local stratum level 1 clocks. Global positioning system (GPS) satellites provide a stratum level 1 clocking source that provides a cost-effective synchronization system.

Stratum level 1 clocks are distributed over networks to provide timing information to a large number of devices. A linear relationship exists between the number of nodes passed and the degradation of the timing quality.

Stratum level 2 timing sources are based on the rare earth element rubidium. Distribution of stratum 2 time information becomes inaccurate more quickly than stratum 1 information.

Stratum level 2 timing is not as accurate as stratum level 1, but the timing is accurate enough to time a large SONET node. SONET nodes are very high-speed networks that are used by service providers to transport time-division multiplexing (TDM) voice calls through networks operating at up to OC-192 speeds (almost 10 Gbp/s). T1 and T3 voice interfaces are provisioned from SONET nodes, such as the Cisco ONS 15454.

NOTE More information on SONET, optical networking, and the ONS 15454 is available in Cisco Self-Study: Building Cisco Metro Optical Networks (METRO), by Dave Warren and Dennis Hartmann (Cisco Press, 2003).

Stratum level 3 timing sources are based on the rare earth element quartz, which has become affordable enough that it is built in to most off-the-shelf wristwatches. Stratum level 3 is accurate enough to time a SONET node, but it quickly loses accuracy when distributed to other nodes. Most T3 (44.736 Mb/s) controllers have built-in oscillators with a stratum level 3 timing source. T3 interfaces multiplex (28) individual T1 interfaces for a total of 672 voice channels.

CUCM has an option to use NTP to obtain time information from a time server. Only the CUCM publisher will communicate with one or more NTP servers. The timing that the publisher receives is synchronized to the subscriber servers. If an external NTP server is not used, CUCM can be manually configured with the date and time. The system time in most servers is a stratum level 4 timing source and should not be relied on to time a production network.

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) is a protocol that allows IP endpoints to obtain their IP settings dynamically from a server. The most important settings include the IP address, subnet mask, default gateway, TFTP server (option 150), and DNS server. CUCM features a DHCP server that was designed to serve Cisco IP Phones only.

Trivial File Transfer Protocol

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol used by Cisco IP Phones to obtain configuration files and their software (binary image load). A CUCM server has to run the TFTP service on at least one server to be able to support Cisco IP Phones.

Domain Name System

Domain Name System (DNS) is a name-resolution protocol that allows IP applications to refer to other systems by logical names rather than IP addresses. A CUCM cluster can be configured to use either DNS or IP addresses.

NTP and DHCP Considerations

NTP can be configured during installation of the CUCM product. NTP can also be configured after the installation procedure using the CUCM Administration web pages.

It is extremely important that all network devices have accurate time information because the system time of CUCM is relevant in the following situations:

■ Cisco IP Phones display date and time information; this information is obtained from CUCM unless an NTP reference is assigned to the phone. NTP references can be configured in date/time groups in CUCM versions 5.x and later. The date/time group is then added to Cisco IP Phone devices.

■ Call details records (CDR) provide time-stamped call reporting, analysis, and billing information. Call management records (CMR) contain quality of service (QoS) information regarding the quality of phone calls, including the number of lost packets (per direction), average jitter (delay variation), and maximum jitter. CMRs are mapped to CDRs.

■ Alarms, log files, and trace files include time stamps with millisecond-level accuracy. One second of processing in a CUCM server can have hundreds of lines of trace output. Troubleshooting calls that involve multiple servers frequently require the correlation of alarm, event, and trace information available in different systems. Correlation of these records is possible only if all devices in the network have the same date and time information.

■ CUCM includes features that rely on date and time. These features include time-of-day routing, certificate-based security features, and remote support.

NOTE Cisco Unified Communications IP Telephony, Part 2 (Cisco Press, 2007) explains the operation of X.509v3 certificates, certificate trust lists, IPsec, transport layer security, and Secure Skinny Client Control Protocol (SCCPS).

Figure 5-1 displays a master reference clock from which the publisher server is synchronizing time. The publisher server redistributes the timing information to the subscriber servers.

Figure 5-1 Network Time Protocol Master Reference Clock

Figure 5-1 Network Time Protocol Master Reference Clock

Subscriber Subscriber Subscriber

CUCM and all network devices should synchronize their time from a stratum level 1 NTP server. To modify NTP configurations in CUCM, navigate to System > NTP Servers from the CUCM Administration web pages, as shown in Figure 5-2. NTP servers can be added, deleted, or modified.

Figure 5-2 Network Time Protocol Configuration

Figure 5-2 Network Time Protocol Configuration


The CUCM DHCP server is designed to serve IP phones in small deployments (maximum of 1000 devices). It provides a subset of the functionality that was provided by the Windows 2000 Server in CUCM versions earlier than CallManager 5.0.

NOTE Due to the CPU load impact, CUCM DHCP server must not be used in deployments larger than 1000 registered devices. The CPU load of the server can be monitored using the Real-Time Monitoring Tool (RTMT). If high CPU load is experienced, the DHCP service should be provided by other devices (DHCP server, switch, or router). RTMT is covered in Cisco Unified Communications IP Telephony, Part 2.

Only one DHCP server can be configured per CUCM cluster; no backup configuration is possible. The CUCM DHCP server can be configured with multiple subnets. DHCP relay must be enabled in remote subnets to allow the DHCP broadcast request packets to be forwarded to the DHCP server. Routers drop all broadcast packets by default, but the packets can be configured with DHCP relay by using the ip helper-address command.

To configure DHCP support on CUCM, follow these steps:

Step 1 Activate the DHCP Monitor Service. Step 2 Add and configure the DHCP server. Step 3 Configure the DHCP subnets.

Navigate to the Cisco Unified Serviceability web pages. From the Tools menu, choose Service Activation. Activate the DHCP Monitor Service by clicking the DHCP Monitor Service check box and then clicking the Save icon. Figure 5-3 is a screen capture of the DHCP Monitor Service activation.

The DHCP server then needs to be configured. Configure the DHCP server from the CUCM Administration page. Navigate to System > DHCP > DHCP Server. The Find and List DHCP Servers page will display. Click the Add New button. Choose the CUCM server that will be acting as the DHCP server from the Host Server drop-down menu. Configure the Primary TFTP Server IP Address field and the Secondary TFTP Server IP Address field. It is advisable to have two CUCM servers running the TFTP service for fault-tolerance purposes. Figure 5-4 shows the DHCP server configuration page options.

Figure 5-3 Service Activation: DHCP Monitor Service

Figure 5-3 Service Activation: DHCP Monitor Service

Figure 5-4 DHCP Server Configuration

The DHCP subnet(s) needs to be configured from the CUCM Administration page. Navigate to System > DHCP > DHCP Subnet. The Find and List DHCP Subnets page will display. Click the Add New button. Choose the DHCP server from the DHCP Server dropdown menu. This is a required field. All fields in the configuration pages that have an asterisk (*) to the upper right of the configuration option are required fields. Specify the subnet IP address, IP address range, primary router IP address, subnet mask, and TFTP servers. Figure 5-5 displays the DHCP subnet configuration page options.

Figure 5-5 DHCP Subnet Configuration

Figure 5-5 DHCP Subnet Configuration

— DHCP Subnet Information-

DHCP Server* Subnet IP Address* Primary Start IP Address* Primary End IP Address Secondary Start IP Address Secondary End IP Address Primary Router IP Address Secondary Router IP Address Subnet Mask* Domain Name Primary DNS IP Address Secondary DNS IP Address TFTP Server Name(Option 66) Primary TFTP Server IP Address(Option 150) Secondary TFTP Server IP Address (Option 150) Bootstrap Server IP Address_

In CUCM releases earlier than 5.0, DHCP services could be provided by the Windows-based operating system of CUCM. If the Windows DHCP server was used and CUCM is upgraded to a CUCM release running the Linux operating system, all DHCP configuration is lost. The Data Migration Assistant (DMA) does not migrate Windows DHCP configuration. DHCP can configured on CUCM servers beginning with Release 5.0.

CUCM can use either IP addresses or names to refer to other IP devices in application settings. When names are used, they need to be resolved to IP addresses by DNS.

Both methods have some advantages:

■ Using IP addresses: The system does not depend on a DNS server. This prevents loss of service when the DNS server cannot be reached. Clients, using DNS, query the server with a name lookup request and receive a reply in which the DNS server resolves the hostname record of the query to an IP address. Eliminating the requirement of a DNS server reduces the danger of DNS configuration errors, DNS outages, and the latency issues involved in sending a query and receiving a response using the DNS model. Troubleshooting is simplified when using IP addresses rather than DNS names because there is no need to perform name resolution.

■ Using DNS: Management is simplified because logical names are easier to remember than IP addresses. If IP addresses change, there is no need to modify any of the application settings that rely on the existing IP address. When DNS is used, the applications point to a DNS name that does not change; the underlying IP address might change at any time with no consequence to the IP addresses that rely on the server. CUCM server addressing is sent to Cisco IP Phones in the CUCM group in the phone's XML configuration file. The addressing sent down to the IP phone can be based on IP addresses or names.

Because of the additional point of failure introduced using DNS, the Cisco best practices recommendation is to not use DNS with CUCM.

Table 5-2 summarizes the advantages and disadvantage of using DNS with CUCM.

Table 5-2 IP Addressing and DNS Comparison

IP Addressing Advantages

DNS Advantages

Does not require a DNS server

Simplifies management because of the use of names rather than numbers

Prevents the IP telephony network from failing if the IP phones lose connection to the DNS server

Enables easier IP address changes because of name-based IP paths

Decreases the amount of time required when a device attempts to contact the Unified CM server

Allows server to IP phone NAT

Simplifies troubleshooting

Before the IP phone can communicate with CUCM, it has to resolve the name of the server. Signaling messages are then exchanged between the Cisco IP Phone and CUCM, as illustrated in Figure 5-6.

Figure 5-6 Call Flow with DNS

Figure 5-6 Call Flow with DNS

DNS Server

When DNS naming is not used in the CUCM cluster, there is no need to resolve the name of the CUCM to an IP address. The signaling between the IP phone and CUCM can be set up faster, and calls can be processed even if the DNS service is not available. CUCM will have higher availability and faster response times by removing any DNS reliance. Call flow without the use of DNS is illustrated in Figure 5-7.

Figure 5-7 Call Flow Without DNS

Figure 5-7 Call Flow Without DNS

IP Phone A 2) RTP Media Path |P Phone B

To change the system to operate without a DNS server, follow these steps:

Step 1 In CUCM Administration, go to System > Server.

Step 2 Click the Find button and select the first (next) available server from the list of CUCM servers.

Step 3 Change the server name to the IP address of the server and save the changes, as shown in Figure 5-8.

NOTE Repeat Steps 2 and 3 for each server in the cluster.

Figure 5-8 Server Configuration

Figure 5-8 Server Configuration

Was this article helpful?

+5 -2


  • Uta
    Where is the CUCM administration window?
    2 years ago
  • luca
    How cucm upload ip phone configuration file to tftp server?
    1 year ago
  • lukas
    How to disable ntp in cucm?
    5 months ago
  • luwam
    What is the option number for the cucm tftp server that is configured in dhcp?
    1 month ago

Post a comment