Replacing Your Old Phone Switch with Cisco CallManager

CCM is a software component running on Cisco-approved server platforms. The CCM makes call-forwarding decisions, controls IP phones, and can support other optional features (for example, conference calling and call transfer). You can think of the CCM as the "brains" of your IP telephony network.

Consider the following scenario. A Cisco IP Phone goes off-hook. The IP phone tells the CCM server that the handset is off-hook using Skinny Client Control Protocol (SCCP). The CCM server, seeing this off-hook condition, instructs the IP phone to play dial tone. The caller dials digits on the IP phone, and SCCP sends these dialed digits to the CCM server.

The CCM server contains a dial plan, a set of instructions for reaching various phone numbers. After the CCM examines the dialed digits and determines which dial plan entry to use, the CCM server signals the destination IP phone that the phone is receiving a call. After the destination phone goes off-hook, a Real-Time Transport Protocol (RTP) stream is set up directly between the IP phones, as shown in Figure 4-1.

Figure 4-1. Call Setup

Administrators configure the CCM server through the Cisco CallManager Administration web interface. If you know the IP address or domain name of a CCM server, you can access the CCM administration interface at the following URL:

http://server_IP_or_name/ccmadmin

note

In CallManager 4.1 and later, https is used instead of http, thus providing a more secure connection.

The various menu options under the administration interface, as shown in Figure 4-2, make configuration intuitive for an administrator. You can even create different administrator accounts, each with a different subset of permissions. For example, you might want help desk personnel to view but not modify IP phone settings, while other personnel might need add/delete/edit permissions.

Figure 4-2. Cisco CallManager Administration Interface

Cisco CallManager is software. Therefore, it needs to run on a server. Specifically, version 4.x (and also version 3.x) of the CCM software runs on a Windows 2000 server. CCM also needs to maintain a database. This database stores information about the CallManager system, such as IP phone configuration and call routing information. Instead of trying to create its own proprietary database, Cisco decided to use a well-established database application, Microsoft's SQL 2000.

Aside from the SQL 2000 database, CCM also leverages a directory containing user information. An attendant can, for example, query this directory to find the phone number associated with a specific user. Cisco includes the Data Connection (DC) Directory with the CCM software. However, if your network already has users entered in Microsoft's Active Directory (AD) or iPlanet (Netscape Directory), the CCM software can leverage either of those directories.

For disaster recovery, we also need some sort of backup application to maintain archival backups of the data contained in the CCM servers. The Cisco Backup and Restore System (BARS) offers one option.

Although the CCM 4.x software runs on a Windows 2000 server, Cisco limits the server platform that can run the CCM software. Supported servers are called Media Convergence Servers (MCS). Although many of these approved servers are Cisco branded, the hardware is often manufactured by IBM or HP. Table 4-1 provides a sampling of these supported platforms, although you should check the Cisco website for the latest specifications before you make a purchase.

Table 4-1. Media Convergence Servers

Server Model	RAM	Hard Drive(s)	Number of IP Phones Supported	Redundant Power
Cisco 7815I	512 MB	One 40 GB ATA	Up to 300	No
Cisco 7825H	1 GB	One 40 GB SATA	Up to 1000	No
Cisco 7825I	1 GB	One 80 GB SATA	Up to 1000	No
Cisco 7835H	2 GB	Two 36 GB SCSI	Up to 2500	Yes
Cisco 7835I	2 GB	Two 36 GB SCSI	Up to 2500	Yes
Cisco 7845H	4 GB	Four 72 GB SCSI	Up to 7500	Yes

note

You do not have to purchase Cisco MCS servers. You can alternately purchase IBM or HP servers if they meet the specifications provided at http://www.cisco.com/go/swonly.

To achieve a PBX environment's level of availability, you can take multiple CCM servers and logically group them together. These groupings of CCMs are called clusters. All CCM servers in a cluster need the same database information, because at any time one server might be called upon to back up another server. To keep the servers' databases in sync (if you'll pardon the boy band reference), Microsoft's SQL 2000 designates a single server in the cluster as the publisher. New database information can only be written to the publisher. The publisher server then sends updates to subscriber servers. These subscriber servers have a read-only copy of the database.

The process of copying database information from the publisher server to subscriber servers is called replication. Database replication includes such information as registration and logging data.

When you make a configuration change, the change is written to the publisher. You can still access the CCM web interface even if the publisher is down. However, you cannot write any changes to the database. When a publisher is again available, it immediately sends configuration changes out to the subscribers. Even though the subscribers only have a read-only copy of the database, there is one instance when we can write information to a subscriber. Specifically, if the publisher is unavailable, call detail records (CDRs) can be stored temporarily on a subscriber. These CDRs are replicated to the publisher when the publisher comes back online.

The CCMs in a cluster also communicate run-time data directly to each other, using a "logical" full-mesh topology. This run-time data includes such information as details of the calls in progress, gateway and IP phone registration, and information about digital signal processor (DSP) resources.

As an example of run-time data, consider an IP phone registering with a CCM. The CCM lets all other CCMs in the cluster know about the registration. Then, the IP phone sends a keepalive message to its "primary" CCM, which it registered with, every 30 seconds. For redundancy, the IP phone also sends a TCP connect message to a backup CCM, so that the IP phone can failover to the backup CCM. The IP phone can also be configured with a third (that is, tertiary) CCM to which it can fallback if both the primary and backup CCMs fail.