Call Manager/Communication Manager/CUCM is the call-processing component of the Cisco Unified Communications System. It is an IP-based communications system integrating voice, video, data, and mobility products and applications. It support multi-channel communication over IP like voice, video, and data traffic within a single network infrastructure. CUCM is managing all three traffic types and interfacing with all standards-based network protocols. Cisco Unified CM runs only as a virtual application; it cannot be deployed directly on a Cisco UCS server. Cisco Unified CME runs within the Cisco IOS or IOS-XE software on Cisco Integrated Services Routers and does not support virtualization.
Call manager provides the following functionality in a UC environment:
- Call processing: Handling Call origination, routing, termination , billing etc.
- Signaling and device control: Setting up signaling connections (Call setup/call teardown) between endpoints and directs devices such as phones, gateways, and conference bridges to establish and tear down streaming connections.
- Dial plan administration: Call routing and digit analysis of all calls.
- Phone feature administration: Providing services such as hold, transfer, forward, conference, speed dial, redial, call park and so on to IP phones and gateways.
- Directory services: Leverages users already configured in corporate-wide directory. Microsoft Active Directory (2000 and 2003), Netscape 4.x, iPlanet 5.1, and Sun ONE 5.2 directory integrations are supported. The local CUCM database is a Lightweight Directory Access Protocol (LDAP)-compliant database (LDAPv3) component in the IBM Informix Database Server (IDS).
- Programming interface to external applications: Programming interface to external applications such as Cisco IP Soft Phone, Cisco IP Communicator, Cisco Unified IP Interactive Voice Response (IP IVR), Cisco Personal Assistant, Cisco Unified Personal Communicator, and CUCM Attendant Console.
- Backup and restore tools: Provides Disaster Recovery System (DRS) to back up and restore the Call manager configuration database. Keeping backups of call details records (CDR), call management records (CMR) and the CDR Analysis and Reporting (CAR) database.
How Call Manager Process and signals a call?
Call Processing:
At the beginning of a call, a user at IP phone A picks up the handset, and a message is sent to CUCM letting CUCM know that the device has gone off-hook. CUCM responds to this stimulus by replying with a message that tells the device to play the dial tone file that is stored in the flash memory of the phone. The user at phone A hears the dial tone and begins dialing the phone number of phone B. SCCP phones send their digits to CUCM as they are pressed (digit by digit), whereas SIP phones send their dialed digits in one message (enbloc signaling) by default. SIP phones have options that allow them to behave similarly to SCCP phones (Keypad Markup Language [KPML] and dial rules). CUCM performs digit analysis against the dialed digits. If a match is found, CUCM routes the call per its configuration. If CUCM does not find a match, a reorder tone is sent to the calling party.
CUCM Signaling and Media Paths:
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 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. The maximum number of servers in the cluster is 20. There is only one publisher which is like a central controller, can install up to 8 subscribers for call processing with enable call manager service in the nodes, the rest of the nodes/subscribers are for special functions like MOH, Conference, TFTP etc. All the servers should run in the same version. Only the publisher needs to synchronize its clock with the lowest stratum NTP server, subscribers will get their time through NTP from publisher only
We can categorize Call manager into two types with its clusters.
Cluster
Cluster can Supports up to 30000 IP phones. The cluster can be scaled to a maximum of 20 Servers in which there can be a maximum of 1 Publisher, 8 Call Processing Subscribers, 2 TFTP servers, 9 Other Servers. Call Processing Servers are the Servers which performs call routing, call controlling and call restriction services.
Mega Cluster
Mega Cluster can supports up to 60000 IP phones and can be scaled to a maximum of 21 Servers in which there can be a maximum of 1 Publisher, 16 Call Processing Subscribers, 2 TFTP Servers, 2 Other servers.
There are two types of data communication between CUCM servers :
1) Database Replication :
– Read/write copy of the database is with the Publisher.
– The database is replicated to all Subscribers from Publisher.
– The Database replication is secured using embedded Red Hat Linux, ip tables dynamic firewall.
2) Cluster Communication :
ICCS(Intra-cluster communication) Signaling :
Used to replicate run-time data such as Registration of devices, Locations bandwidth, Shared Media Resources.This signaling runs only between the servers that have the “ccm.exe” service i.e the Call manager service running (Call Processing agents). Uses TCP ports 8002-8004. A minimum of 1.544 Mbps (T1) bandwidth is required for Intra-Cluster Communication Signaling (ICCS) traffic between sites.
CDR & CAR :
Call Detail Records are logged by the Call Processing Engine taking the call. These are periodically pushed to the Publisher server. The Cisco CAR or any third party billing application server always points to and collects data from the Publisher.
Network Solutions 