Cisco Unified Communication Manager Part-1

Cisco Unified Communication Manager Part-1

 A Cisco Unified Communications (UC) deployment relies on Cisco Unified Communications Manager (CUCM) formerly known as Cisco Call Manager for call processing, device control, call routing, mobility services, phone/system feature administration, and dial plan administration. CUCM plays core part in a UC deployment to provide the essential call-routing functions necessary to deploy voicemail, unified messaging, presence, video to the desktop, videoconferencing and TelePresence. CUCM (Cisco Unified Communications Manager) uses SIP or SCCP to communicate with Cisco IP Phones for call setup and teardown tasks. All supplementary services (call hold, park, transfer, conference) are transported as call-signaling events.

A CUCM cluster can have up to 20 servers in it. The cluster consists of one publisher server, which maintains the read/write copy of the CUCM’s database. The publisher replicates the database as a read-only database to up to eight subscriber servers in the CUCM cluster. Each cluster has a restriction of four subscriber servers that can perform active call processing. Additional subscriber servers are dedicated standby servers in case the active subscriber server is not available. The additional 11 servers in the cluster are responsible for various services, including TFTP and media resources (conferencing, music on hold, transcoding).

The database in Cisco Communication Manager cluster replicates the configuration information in a hub-and-spoke topology (one publisher, up to eight subscribers). CUCM nodes also use a second communication method to replicate some runtime data (call forwarding, message waiting indicators, hunt login status) using a master-master replication technology referred to as user-facing features (UFF). UFF provides a full-mesh replication topology allowing dynamic registration of active call information that changes much more frequently than the database changes.

The data in the CUCM database is divided into two types, which are described below.

 

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 in the publisher server only. Subscriber servers have a local read-only copy of the database that is replicated downstream from the publisher. If the publisher becomes unavailable, the subscriber server’s replicated  data can be used to process calls locally. Database replication is unidirectional, from the publisher to the subscribers. Only call detail records (CDR) and call management records (CMR) are replicated from the subscriber servers to the publisher. All other configuration information is downloaded from the publisher. CDRs contain call detail fields such as calling party, called party, start time, stop time, call duration, and chargeback (if applicable). The CDRs provided by CUCM are standard for a phone switch/PBX. CMRs provide QoS details regarding the number of packets transmitted and received, maximum jitter, average jitter, mean opinion score (MoS) rating of the call, and so on. CMRs are useful for troubleshooting QoS issues (packet loss, delay, and jitter) that could affect voice quality.

User-Facing Features

The publisher is the only server in the CUCM cluster with a read/write copy of the database, and all configuration changes should be made on the publisher. The publisher then replicates these changes to the read-only subscriber databases. Call-processing redundancy can be provided by subscriber servers, but the single-publisher model represents a single point of failure from the perspective of providing moves, adds, and changes (MAC). The publisher was also the only server in the cluster responsible for call forwarding, extension mobility login, and message-waiting indicator changes in versions of CUCM before CUCM 6.0. CUCM treats a small 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 referred to as user-facing features (UFF). UFF data is replicated between all servers in the cluster.

CUCM Call-Processing Redundancy

A CUCM cluster is a group of physical servers working as a single IP PBX system. A cluster can contain up to 20 servers, of which a maximum of eight servers can run the Cisco CallManager service performing call processing in a cluster. Any additional servers above the eight can be used to provide added functionality to support the telephony deployment (for example, TFTP servers, media resources such as conference bridges, music on hold [MOH], MTP, annunciator, and transcoding) and/or support third-party integrations for add-on applications through APIs. CUCM call-processing redundancy is implemented by grouping servers running the Cisco CallManager service into CM groups. A CM group is a prioritized list of up to three call-processing servers.

The following rules apply for the CM groups:

·         Many CM groups can exist in the same cluster.

·          Each call-processing server can be assigned to more than one CM group.

·          Each device has an assigned CM group that will determine the primary, secondary, and tertiary servers to which it can register.

 

Cisco IP Phones register with their primary server. When idle, the Cisco IP Phones and CUCM exchange keepalives to ensure that reachability between the devices is maintained. Cisco IP Phones running SCCP establish a TCP session with their primary and secondary servers and exchange TCP keepalives every 30 seconds by default. When the connection to the primary server is lost (no keepalives received for three keepalives), the Cisco IP Phone registers to the secondary server and establishes a TCP connection with the tertiary call-processing server. The Cisco IP Phone continuously tries to reestablish a connection with the primary server. If the Cisco IP Phone is successful in reaching the primary server when registered to the secondary, the IP Phone waits 120 seconds for the default connection monitor duration timer to expire before reregistering with the primary server. The connection monitor duration alleviates the side effects of an oscillating/flapping WAN link, where the WAN is continuously going up and down. The connection monitor duration is a device pool configuration parameter. A 1:1 CUCM call-processing redundancy deployment design guarantees that Cisco IP Phone registrations will never overwhelm the backup servers if there are concurrent primary server failures on different primary servers. The 1:1 design has an increased server count compared to other redundancy design models. This design is not the most cost-effective, but it offers the highest level of fault tolerance.

 

Each cluster must also provide a TFTP service running on a CUCM server. The TFTP service is responsible for delivering IP phone configurations, firmware (Load ID)  upgrades to telephones, and files such as backgrounds and ringtones. The server running the TFTP service might experience significant load in a large cluster. Depending on the number of devices that a server is supporting, you can run the TFTP service on a dedicated server, on the database publisher server, or on any other server in the cluster.

Cluster redundancy model leveraging Cisco 7845 Media Convergence Servers (MCS) or Cisco Unified Computing System. Each 7845/UCS server can accommodate up to a maximum of 7500 Cisco IP Phones. We are going to cover three different scenarios. Scenario one includes three servers, but only two servers would be required if the cluster had fewer than 1250 phones (1000 phones for the 7835 model server). A cluster consisting of 1250 to 7500 phones would require a server dedicated to maintaining the publisher and TFTP functionality.

Scenario one uses two servers for call-processing functionality. One server is the primary call-processing agent, while the other server is the backup call-processing agent. Instead of dedicating a server to a backup-only role, registration-based load sharing can occur between the two servers, and the two servers can back each other up (active/active load sharing). This configuration would need to be manually configured in the CM group that is assigned to the phones. Server A would be the primary for phones 1–3750 and the backup for phones 3751–7500, while server B would be the primary for phones 3751–7500 and the backup for phones 1–3750.

Scenario two leverages everything you covered in scenario one but has doubled the number of call-processing servers and has a dedicated TFTP server. The Cisco CUCM Solution recommends one dedicated TFTP server in a cluster of 7500 Cisco IP Phones. Notice that there are two active call-processing servers with two dedicated backup servers. Because each CUCM cluster can have up to four active call-processing servers running the CallManager service, a load-sharing configuration like that covered in scenario one can be used to get the full benefit of all four servers.

Scenario three leverages everything discussed in the two prior scenarios, but the number of call-processing servers has again doubled when compared against the last model covered. Load sharing cannot occur in this model because the CUCM is limited to four. Cisco has a super-clustering model where more than four active servers can be leveraged, but this is a model that involves Cisco Advanced Services design and tuning services. Two TFTP servers must be used in this model because of the number of phones.

Best practice is to enable the TFTP service on at least two servers in the CUCM cluster in all the models to provide TFTP redundancy. Although the 1:1 redundancy design model provides the highest level of redundancy, it might be excessive. It is unlikely that multiple server failures will occur at the same time, but beware of Murphy’s Law! If it can happen, it will. Because of the low probability of multiple simultaneous server outages and server cost, some environments choose to use a 2:1 redundancy design

CUCM Signaling and Media Paths

CUCM uses SIP or SCCP to communicate with Cisco IP Phones for call setup and teardown tasks. All supplementary services (call hold, park, transfer, conference) are transported as call-signaling events. When the called party picks up his ringing phone, CUCM completes the call setup phase, resulting in a media exchange that occurs directly between the Cisco IP Phones across the IP network using the Real-Time Transport Protocol (RTP). CUCM is not involved in any call processing after the call has been set up unless a softkey feature is initiated. The CUCM server could be unplugged from the network during the call and the calls would survive (call survivability/call preservation). The users on the active call would not be aware of the CUCM failure unless they attempted to use a feature on the phone during the call. All supplementary services will fail during the CUCM outage as indicated by the LCD screen message indicated on the IP Phone (CM Down, Features Disabled). CUCM is involved only in call setup, teardown, and the invocation of supplementary service features.

Basic IP Telephony Call

The following steps occur during a call from phone A to B:

1. The calling party at IP phone A picks up the handset (goes off hook), resulting in an SCCP or SIP message being   sent to CUCM, indicating that the device has gone off hook.

2. CUCM responds to this stimulus message with a response message that tells the device to play the dial tone file that is stored in the flash memory of the phone.

3. The calling party at phone A then hears dial tone and begins dialing the phone number of phone B (called party). SCCP phones send their digits to CUCM as they are pressed (digit by digit), whereas SIP phones send their dialed digits digit by digit or in one message (enbloc signaling), depending on the generation of Cisco IP Phone. Type B SIP-based Cisco phones use Keypad Markup Language (KPML) by default. KPML sends digits to CUCM in real time as they are dialed unless SIP dial rules are leveraged. SIP dial rules always send their digits enbloc regardless of whether the Cisco Phone is a Type A (7940, 7960) or Type B Phone (7970, 79x1, 79x2, 79x5, 7906). Type A Cisco Phones do not support KPML, resulting in enbloc signaling by default

4. Regardless of how the digits are collected, CUCM performs digit analysis against the dialed digits collected from the calling party.

5. When a match is found in the call-routing database, CUCM routes (steers) the call to the called party based on the call-routing configuration. If CUCM does not find a match, a reorder tone is sent to the calling party.

6. CUCM sends a signaling event to the calling party (phone A) to initiate ringback, so the user at phone A will hear the ringback tone. CUCM also signals the call to the called (destination) phone (ringdown). Additional information is provided to the phones to indicate the calling and called party name and number. (Phone A’s LCD will indicate the called party name and number, while phone B’s LCD will indicate the calling party name and number).