Cisco Unified Communications Manager Design Overview

Deployment Models

There are several deployment models for Cisco UCM based on the following factors:

•Number of call processing agent clusters

•Number of IP phones

•Locations of the call processing cluster(s) and IP phones

Single Site

The single-site model for Cisco Unified Communications consists of a call processing agent cluster located at a single site, or campus, with no telephony services provided over an IP WAN.

Multisite WAN with Centralized Call Processing

The model for a multisite WAN deployment with centralized call processing consists of a single call processing cluster that provides services for many remote sites and uses the IP WAN to transport Cisco Unified Communications traffic between the sites.

Multisite WAN with Distributed Call Processing

The model for a multisite WAN deployment with distributed call processing consists of multiple independent sites, each with its own call processing cluster connected to an IP WAN that carries voice traffic between the distributed sites

Clustering Over the IP WAN

It is possible to deploy a single UCM cluster across multiple sites that are connected by a QoS-enabled IP WAN. For specific WAN requirements, refer to the Cisco Unified Communications Solution Reference Network Design:

Each deployment model has benefits and network requirements that should be considered. Further descriptions of the Cisco Unified Communications Manager Deployment models are available within the Cisco Unified Communications Solution Reference Network Design.

The design considerations presented in this chapter were based on the use of a Multisite WAN with Centralized Call Processing deployment. This model consists of a centralized call processing cluster and one or more remote sites using an IP WAN to transport voice and call control.

Figure 7-2 is an example of a Multisite WAN with Centralized Call Processing with one branch location.

Figure 7-2 Multisite with Centralized Call Processing

Cisco Unified Communications Manager Configuration

Wireless phones (and softphones) are inherently mobile so controlling the admission of their calls into a network is critical to maintaining the quality of calls by avoiding traffic collisions leading to loss, jitter and delay perceptible to the user. The next two sections will discuss CAC and Device Mobility and how Device Mobility configuration is important to maintaining accurate CAC decisions.

Call Admission Control

This chapter discusses Call Admission Control (CAC) by the Cisco UCM for those devices on the physical IP LAN/WAN, in the context of a single cluster design. This applies to wireless phones (Cisco 7920/7921) from the point of entry into the physical network. CAC must also be considered on the wireless network and is discussed in detail in the Chapter 2, "WLAN Quality of Service."

CAC in the context of this chapter is a concept that applies to real-time (voice) traffic only, not data traffic. If an influx of data traffic oversubscribes a particular link in the network, queuing, buffering, and packet drop decisions resolve the congestion. The extra traffic is simply delayed until the interface becomes available to send the traffic, or, if traffic is dropped, protocol timeouts or user-initiated actions will trigger the re-transmission of the information.

Network congestion cannot be resolved in this manner when real-time traffic, sensitive to both latency and packet loss, is present, without jeopardizing the quality of service (QoS) expected by the users of that traffic. For real-time delay-sensitive traffic such as voice, it is better to deny network access under congestion conditions than to allow traffic onto the network to be dropped and delayed, resulting in sporadic impairments perceived by the users.

QoS protects voice from being overrun by data. CAC on the other hand, protects voice from voice. If a link can support X calls, allowing X + 1 calls will have a negative impact on calls being carried by that link. CAC is therefore a deterministic and informed decision that is made before a voice call is established and is based on whether the required network resources are available to provide suitable QoS for the new call.

Considering Figure 7-3, because it is based on a packet-switched network (the IP network), no circuits are established to setup an IP telephony call. Instead, the IP packets containing the voice samples are simply routed across the IP network together with other types of data packets. QoS is used to differentiate the voice packets from the data packets, but bandwidth resources, especially on IP WAN links, are not infinite. Therefore, network administrators dedicate a certain amount of "priority" bandwidth to voice traffic on each IP WAN link. However, once the provisioned bandwidth has been fully used, the IP telephony system must reject subsequent calls to avoid oversubscription of the priority queue on the IP WAN link, which would cause quality degradation for all voice calls.

Figure 7-3 CAC Example

Most CAC control mechanisms fall into two categories:

•Topology-unaware call admission control—Based on a static configuration within the call processing agent

•Topology-aware call admission control—Based on communication between the call processing agent and the network about the available resources

Topology-unaware CAC is based on the UCM construct of CAC static locations, with each branch site belonging to a unique location. All devices in a site are assigned to the same location. Based on the amount of bandwidth available, each site would support a specific number of calls over the IP WAN.

Topology-aware CAC limits the number of calls across the IP WAN using real-time communications about the availability of network resources between the UCM and the network. This CAC mechanism works well in environments with constant topology changes as it can dynamically adjust to the changes, or with non hub-and-spoke WAN topologies. Resource Reservation Protocol (RSVP) is the primary industry-standard signaling protocol that enables an application to reserve bandwidth dynamically across an IP network. Using RSVP, applications can request a certain amount of bandwidth for a data flow across a network (for example, a voice call) and can receive an indication of the outcome of the reservation based on actual resource availability.

For this version of the design guide, static locations-based CAC (topology-unaware) was used. For an in-depth discussion of CAC, refer to Cisco Unified Communications Solution Reference Network Design at the following URL:

Device Mobility

Mobility of wireless phones includes not just moving between access points within a building but also moving between buildings and locations. If a wireless phone user is defined with a UCM region and location specific to their home location (for example, San Jose) takes their phone to a branch office in somewhere else (for example, in RTP), it is important that device mobility is configured so the WAN links between these location are not oversubscribed. Without device mobility, when the users phone registers in the branch location (RTP), the UCM configuration for the phone assumes they have registered in San Jose. If the user dials a PSTN number in RTP, UCM may use a gateway in San Jose and also not deduct bandwidth that the phone is using over the WAN link between RTP and San Jose, possibly causing and over-subscription environment.

Device mobility allows UCM to make device configuration decisions based on the subnet of the device that is registering. Some of the device mobility elements include:

Roaming Sensitive Settings

The parameters under these settings override the device-level settings when the device is roaming within or outside a device mobility group. The parameters included in these settings are:

•Date/Time Group

•Region

•Media Resource Group List

•Location

•Network Locale

•SRST Reference

•Physical Location

•Device Mobility Group

The roaming sensitive settings primarily help in achieving proper CAC and voice codec selection, because the location and region configurations are used based on the device's roaming device pool. The roaming sensitive settings also update the media resource group list (MRGL) so that appropriate remote media resources are used for music on hold, conferencing, transcoding, and so forth, thus utilizing the network efficiently. The roaming sensitive settings also update the Survivable Remote Site Telephony (SRST) gateway. Mobile users register to a different SRST gateway while roaming.

Device Mobility Related Settings

The parameters under these settings will override the device-level settings only when the device is roaming within a device mobility group. The parameters included in these settings are:

•Device Mobility Calling Search Space

•AAR Calling Search Space

•AAR Group

The device mobility related settings affect the dial plan because the calling search space dictates the patterns that can be dialed or the devices that can be reached. Device mobility group, as explained earlier, defines a logical group of sites with similar dialing patterns (for example, sites having the same PSTN access codes and so forth). With this guideline, all sites have similar dialing patterns in the site-specific calling search spaces. Sites having different dialing behavior are in a different device mobility group. A user roaming within a device mobility group may preserve his dialing behavior at the remote location even after receiving a new calling search space. A user roaming outside the device mobility group may still preserve his dialing behavior at the remote location because he uses his home calling search space. However, if a device mobility group is defined with sites having different dialing patterns (for example, sites having different PSTN access codes), then a user roaming within that device mobility group might not preserve his same dialing behavior at all locations. A user might have to dial digits differently at different locations after receiving a new calling search space at each location.