Cisco Unified Communications Manager (CUCM) is an IP telephony call-processing solution. It provides distributed, scalable enterprise call processing and IP telephony features for IP phones, Voice over IP (VoIP) gateways, and multimedia applications and devices.
CUCM can be deployed using several different models, as shown in Figure 1-1:
){kind=link}
- Single site: In this model, CUCM provides call processing at a single site, with no telephony being implemented over an IP WAN.
- Multisite WAN with centralized call processing: In this case, CUCM is deployed at a central site, and it provides call processing for a number of sites, with VoIP/IP telephony traffic being carried over an IP WAN between sites.
- Multisite WAN with distributed call processing: When using this model, call-processing agents such as CUCM are deployed at multiple sites, with VoIP/IP telephony traffic being transported over an IP WAN between sites.
- Clustering over the IP WAN: This involves deploying a single CUCM cluster with constituent CUCM servers spread across several sites connected by the WAN.
)
Figure 1-1. CUCM Deployment Models
Several best practices are associated with these different types of deployment models.
Best practices for the single-site model include the following:
- The single-site model is suited for enterprises where most calls are made to destinations within the same site or to the public switched telephone network (PSTN).
- Deploy a highly available network infrastructure, with inline power, QoS, and security for phones.
- Use the Media Gateway Control Protocol (MGCP) between CUCM and voice gateways (assuming H.323 functionality is not required).
- Use the G.711 codec.
Best practices for the multisite WAN with centralized call-processing model include the following:
- Consider the factors that typically motivate the decision to deploy this model (or the multisite WAN with distributed call-processing model), including WAN bandwidth, delay limitations, scalability, management, cost, features, and so on.
- Use CUCM locations for call admission control (CAC).
- Consider deploying Survivable Remote Site Telephony (SRST). For Skinny Client Control Protocol (SCCP) phones, use SRST or Cisco Unified Communications Manager Express (CME) in SRST mode, and for Session Initiation Protocol (SIP) phones, use SIP SRST. If you are using MGCP phones, use MGCP gateway fallback.
- Minimize delay between CUCM and remote sites as much as possible.
Best practices for the multisite WAN with distributed call-processing model include the following:
- Follow general guidelines for the single-site and multisite WAN with centralized call-processing models, in addition to other specific best practices for this model.
- Use H.323 gatekeepers for CAC and dial plan resolution. Alternatively, use SIP proxies for dial plan resolution.
- Ensure high availability for gatekeepers by using mechanisms such as Hot Standby Router Protocol (HSRP) gatekeeper pairs, gatekeeper clustering, and redundancy using multiple gatekeepers. Similarly, if you are using SIP proxies, ensure that there is redundancy for these devices.
Best practices for clustering over the IP WAN include the following:
- If you have between two and four sites, consider a local failover deployment model, with CUCM subscriber and backup servers at the same site with no WAN between them.
- If you have up to eight sites, consider a remote failover deployment, with CUCM subscribers backed up by subscribers at another site.
- Ensure that the maximum one-way delay between CUCM server does not exceed 40 milliseconds (80 milliseconds round-trip).
- Minimize jitter, congestion, and packet loss for Intra-Cluster Communication Signaling (ICCS).
- Provision bandwidth between servers in accordance with expected call volume and device types/numbers.
During (at least) the initial deployment phase for CUCM, CUCM commonly must coexist with a traditional PBX infrastructure.
There are two common approaches to migration from a PBX infrastructure to IP telephony:
Phased migration: In this case, there is a small initial IP telephony deployment, and connectivity between CUCM and the PBX is provided via a VoIP gateway, using T1/E1 CAS/analog or T1/E1 PRI.
The signaling protocol chosen for connectivity can include regular PRI, QSIG PRI, SIP, or H.323. QSIG allows the greatest level of feature transparency between CUCM and PBX.
The migration itself takes place in several phases, with users being gradually moved over from the PBX to CUCM.
- Parallel cutover: This migration approach involves the deployment of a complete, parallel IP telephony infrastructure, including the placement of a second (IP) phone on each user’s desk. The legacy PBX and infrastructure can be left in place until the IP telephony infrastructure is proven to operate correctly and users have developed a high degree of confidence in it.
Codecs and Regions
In a VoIP network, calls typically have to transit both LAN links, where bandwidth is usually abundant, and WAN links, where it usually is not. Different codecs often have different associated bandwidth requirements, and in CUCM, it is possible to specify which type of audio and video codecs should be used when voice traffic transit links between different parts of the network using a mechanism called regions.
One method of implementing CAC with CUCM is to use locations. Locations CAC is dependent on regions because regions control the particular codec and the amount of bandwidth that needs to be allocated for a call when voice traffic crosses the network. Locations CAC is described in the section, “Call Admission Control,” later in this e-book.
As shown in Figure 1-2, you can configure and modify regions within CUCM Administration by navigating to System, Region.
){kind=link}
)
Figure 1-2. Region Configuration
You use regions to specify the codec and maximum video bandwidth that can be used on calls between devices. Every device is in a region, and you assign a device to a region by specifying a region within a device pool and then assigning the device pool to a device.
The default codec for audio calls is G.711, so if this is the only codec used in a network, it is not necessary to configure regions.