Chapter 1: Cisco Unified Communications Manager Architecture

CUCM signals the calling party to initiate ringback, so the user at phone A will hear the ringback tone. CUCM also signals the call to the destination phone, which plays the ringdown tone. Additional information is provided to the phones to indicate the calling and called party name and number. (Phone A will show the destination device name and number, and phone B will show the calling party name and number.)

When the user at phone B accepts the call, CUCM sends a message to the devices letting them know the IPv4 socket (IPv4 address and port number) information in which they should communicate for the duration of the call. The RTP media path opens directly between the two phones.

The Cisco IP Phones require no further communication with CUCM until either phone invokes a feature, such as call transfer, call conferencing, or call termination.

CUCM Hardware, Software, and Clustering

CUCM Release 6.0 is a complete hardware and software solution that works as a network appliance. A network appliance is a closed system that supports only Cisco-authorized applications and utilities. Goals of the appliance model are to simplify the installation and upgrade of the system and to hide the underlying operating system. An appliance-based model makes it possible for an administrator to install, implement, and manage a CUCM server without requiring knowledge of or having access to the underlying operating system.

The CUCM appliance has these features:

• Complete hardware and software solution.

CUCM servers are preinstalled with all software that is required to operate, maintain, secure, and manage a server or cluster of servers (including Cisco Security Agent).

CUCM is also provided as a software-only product, which may be installed on supported Cisco Media Convergence Servers (MCS) or Cisco-approved third-party server platforms.

• Appliance operating system provides ease of installation and upgrade, while also providing security and reliability.

• You can upgrade CUCM servers while they continue to process calls.

• System administration is performed via graphical user interface (GUI), command-line interface (CLI), and through documented APIs for third-party access.

• Outputs a variety of management parameters via a published interface to provide information to approved management applications, such as NetIQ Vivinet Manager, HP OpenView, and Integrated Research PROGNOSIS.

• Appliance operates with or without keyboard, mouse, and monitor (also known as headed or headless). Third-party access is allowed via documented APIs only.

• CUCM supports clustering of servers for the purpose of redundancy and load sharing. Database redundancy is provided by sharing a common database across multiple servers. Call-processing redundancy is achieved through the Call Manager Group setting, in which multiple servers are assigned to a device for the purposes of providing fault tolerance.

A CUCM cluster can have up to 20 servers in it. Only one publisher server is allowed in the cluster. The publisher houses the read/write copy of the database. Up to eight subscriber servers can be in the cluster, with the restriction that only four of the subscriber servers can perform active call processing. If more than four subscriber servers are used in a cluster, the additional servers are dedicated standby servers in case the active subscriber server is not available. The other 11 servers in the cluster can be responsible for various services, including TFTP and media resources (conferencing, music on hold, transcoding).

CUCM Cluster

Clustering allows the network to scale to several thousands of endpoints, provides redundancy in case of network or server failure, and provides a central point of administration. Figure 1-5 displays a Publisher database synchronizing database components to all the other servers in the cluster. The servers running the CCM.exe process are performing call processing, and the other servers are taking on special roles described in later chapters of this book. CUCM clustering creates scalability by segregating processes to other machines, which increases performance.

Figure 1-5

CUCM Cluster

Device settings are stored in the IBM IDS database. The database is the repository for service parameters, features, device configurations, and dial plan configurations.

The database replicates nearly all configuration information in a hub-and-spoke topology (one publisher, many subscribers). CUCM nodes also use a second communication method to replicate runtime data using a mesh topology. (Every node updates every other node.) A mesh topology of information sharing provides dynamic registration and active call information that changes much more frequently than database changes. Real-time mesh replication is used to communicate newly registered phones, gateways, and digital signal processor (DSP) resources, guaranteeing optimum call routing.

Cisco 7800 Series Media Convergence Servers

Although it is possible for CUCM to run on most computers, Cisco supports CUCM running only on Cisco-approved hardware that they will support. The minimum hardware requirements for CUCM Release 6.0 are as follows:

• 2-GHz processor

• 2 GB RAM

• 72-GB hard disk

Minimum requirements for CUCM 6 are the same as for Cisco Unified CallManager Version 5, but only specific MCS models are approved.

The 7800 series servers are available in the –H or –I variants. –H stands for Hewlett-Packard, and –I stands for IBM server platforms. The 7825 server is a 19-inch or 23-inch rack-mountable server that provides a single SATA hard drive and one power supply. The 7835 server improves reliability and performance by including hot-swappable SCSI hard drives, hardware RAID 1 disc duplexing, and redundant power supplies. The 7845 improves reliability and performance by providing a second CPU and a backup fan assembly.

You can find the most detailed, current Cisco hardware specifications at http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure0900aecd8062a4f9.html.

CUCM must be installed on a server that meets Cisco configuration standards. Cisco actively collaborates with two server hardware manufacturers to meet this requirement: Hewlett-Packard (HP) and IBM. You can find additional information at the following sites:

• Cisco-approved IBM server solutions: http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure0900aecd80091615.html

• Cisco-approved HP server solutions: http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure09186a0080107d79.html

Cisco UC Operating System

The CUCM operating system is based on Red Hat Linux. Operating system and application updates are provided by Cisco through patches that are digitally signed by Cisco. Unsupported software and applications (not digitally signed by Cisco) cannot be uploaded or installed into the system.

Root access to the file system is not permitted. The operating system has been hardened by disabling all unnecessary accounts and services. There is also no access to native operating

system debug interfaces. Traces, alarms, and performance counters can be enabled and monitored through the CUCM GUI. Some files and directories are accessible through the Cisco CLI and GUI for maintenance purposes.

Remote-access support allows Cisco Technical Assistance Center (TAC) engineers to remotely access the CUCM server for a restricted time interval. Remote-access support can be enabled in CUCM serviceability tools.

The IBM IDS is the database for the Cisco UC applications. The IDS database installation and configuration is scripted into the CUCM installation DVDs. No UNIX or IBM IDS database knowledge is required to configure and operate CUCM.

Cisco Secure Agent is included with the appliance to provide protection against known and unknown attacks. Cisco Secure Agent is a host-based intrusion prevention system (HIPS).

A DHCP server is integrated into CUCM to provide IP telephony devices with their IP addressing requirements.

The Cisco UC operating system is also used for these Cisco UC applications:

• Cisco Emergency Responder 2.0

• Unity Connection 2.0

• Cisco Unified Presence 6.0

Cisco UC Database

The data in the CUCM database is divided into two types, as described in the sections that follow.

Static Configuration Data

Static configuration data is created as part of the configuration of the CUCM cluster. Read/write access to this data is provided for the publisher only. Subscribers provide only read-only access to this data. If the publisher becomes unavailable, the subscriber data can be used to process calls, but it cannot be modified. Database replication is unidirectional, from the publisher to the subscribers. Only CDRs and CMRs are replicated from the subscriber servers to the publisher. All other configuration information is downloaded from the publisher.

User-Facing Features

You have learned that the publisher is the only server with a read-write copy of the database, and all configuration changes should be made on the publisher. These changes are then replicated downstream to the subscribers. This model represents a single point of failure from the perspective of moves, adds, and changes (MAC). The problem is further exacerbated because the publisher was the only server in the cluster responsible for call-forwarding changes, extension mobility logins, and message-waiting indicators before CUCM 6.0.

CUCM 6.0 treats a portion of the database as dynamic configuration data. Read/write access to dynamic configuration data is provided on all servers, allowing certain information to be modified if the publisher server is unavailable. The dynamic information that can be changed during a publisher outage is known as user-facing features (UFF). UFF data is replicated from the subscriber servers where the change was initiated to all other subscriber servers in the CUCM cluster.

Examples of UFFs include the following:

• Call Forward All (CFA)

• Message Waiting Indication (MWI)

• Privacy, Enable/Disable

• Do Not Disturb, Enable/Disable (DND)

• Extension Mobility Login (EM)

• Hunt Group Login Status

• Monitor (future use)

• Device Mobility

• CTI CAPF Status (Computer Telephony Integration, Certificate Authority Proxy Function)

The services listed in Table 1-1 rely on the availability of the publisher server regardless of the version of CUCM used.

Table 1-1 Publisher Server Required Services

Database Access Control

Database access is secured using the embedded Red Hat, iptables dynamic firewall and a database security password.

The procedure to allow new subscribers to access the database on the publisher is as follows:

Step 1 Add the subscriber to the publisher database using CUCM Administration.

Step 2 During installation of the subscriber, enter the same database security password that was entered during installation of the publisher.

After this configuration, the following process occurs to replicate the database from the publisher to the newly added subscriber:

1. The subscriber attempts to establish a connection to the publisher database using the database management channel.

2. The publisher verifies the subscriber's authenticity and adds the subscriber's IP address to its dynamic firewall (iptables).

3. The subscriber is allowed to access the publisher database.

4. The database content is replicated from the publisher to the subscriber.

Figure 1-6 illustrates the iptables firewall allowing subscriber access to the publisher database.

You can find CUCM 6.0 TCP and UDP port usage information at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/6_0/60plrev1.pdf.

Figure 1-6

Database Access Control

CUCM Licensing

Licensing is implemented in CUCM beginning with Release 5.0. Administration of license management is done through CUCM GUI administration, allowing accurate tracking of active device registrations compared to the license units that have been purchased. License enforcement occurs at the time of phone provisioning and CUCM service activation.

The publisher is the only licensing server. The licensing server is the logical component that keeps track of the licenses purchased and the licenses used. If the publisher fails, no new phones can register, and no configuration changes will be allowed. Existing phones will continue to operate during a publisher outage.

CUCM tracks the license compliance for devices, applications, and software as follows:

• Device units licenses: The maximum number of provisioned devices in the CUCM database will be tracked and enforced. Route points and CTI ports are not enforced.

• Application licenses: Application licenses are required for every call-processing server running the CallManager service. Application licenses are tied to the MAC address of the network interface card (NIC) of the server.

• Software licenses: Software licenses are tied to the major version of the software. Software licenses are required for upgrade to CUCM 6.

Licenses are created and distributed in accordance with the Cisco FlexLM process. Cisco product license registration is performed at http://www.cisco.com/go/license.

These two types of product IDs are available:

• Cisco device license units: Cisco device license units (DLU) are for Cisco devices only.

• Third-party device license units: Third-party DLUs can be converted to Cisco units, but not vice versa.

CUCM tracks the number of units required by each device, as shown in Figure 1-7. Each device type corresponds to a fixed number of units.

The number of DLUs consumed per device depends on the device type and capabilities of the phone.