Table Of Contents

Bandwidth Provisioning and QoS Considerations

What's New in This Chapter

Unified CCE Network Architecture Overview

Network Segments

IP-Based Prioritization and QoS

UDP Heartbeat and TCP Keep-Alive

HSRP-Enabled Network

RSVP

Traffic Flow

Public Network Traffic Flow

Private Network Traffic Flow

Bandwidth and Latency Requirements

Quality of Service

Where to Mark Traffic

How to Mark Traffic

QoS Configuration

Configuring QoS on Unified ICM Router and PG

Configuring QoS on Cisco IOS Devices

QoS Performance Monitoring

Bandwidth Provisioning

Bandwidth Requirements for Unified CCE Public and Private Networks

Public Network Bandwidth

Private Network Bandwidth

Bandwidth Requirements for Unified CCE Clustering Over the WAN

Bandwidth Requirements for Gateway PG to System PG

Bandwidth Requirements for Unified CCE Gateway PG to Central Controller

Bandwidth Requirements for Unified CCE Gateway PG to System PG

Autoconfiguration

Best Practices and Options for Gateway PG and Unified CCE

Bandwidth Requirements and QoS for Agent and Supervisor Desktops

Bandwidth Requirements for CTI OS Agent Desktop

CTI-OS Client/Server Traffic Flows and Bandwidth Requirements

Silent Monitoring Bandwidth Usage

CTI OS Server Bandwidth Calculator

Best Practices and Options for CTI OS Server and CTI OS Agent Desktop

Bandwidth Requirements for Cisco Agent Desktop

Silent Monitoring Bandwidth Usage

Cisco Agent Desktop Applications Bandwidth Usage

Best Practices and Recommendations for Cisco Agent Desktop Service Placement

Bandwidth Requirements for a Distributor AW with HDS and Reporting

Report Data Bandwidth

WebView Server Bandwidth

Reports Bandwidth

Bandwidth Requirements for Cisco E-Mail Manager

Bandwidth and Latency Requirements for the User List Tool

Bandwidth Provisioning and QoS Considerations

---

Last revised on: November 13, 2008

 

This chapter presents an overview of the Unified CCE network architecture, deployment characteristics of the network, and provisioning requirements of the Unified CCE network. Essential network architecture concepts are introduced, including network segments, keep-alive (heartbeat) traffic, flow categorization, IP-based prioritization and segmentation, and bandwidth and latency requirements. Provisioning guidelines are presented for network traffic flows between remote components over the WAN, including recommendations on how to apply proper Quality of Service (QoS) to WAN traffic flows. For a more detailed description of the Unified CCE architecture and various component internetworking, see Architecture Overview, page 1-1.

Cisco Unified CCE has traditionally been deployed using private, point-to-point leased-line network connections for both its private (Central Controller or Peripheral Gateway, side-to-side) as well as public (Peripheral Gateway to Central Controller) WAN network structure. Optimal network performance characteristics (and route diversity for the fault tolerant failover mechanisms) are provided to the Unified CCE application only through dedicated private facilities, redundant IP routers, and appropriate priority queuing.

Enterprises deploying networks that share multiple traffic classes, of course, prefer to maintain their existing infrastructure rather than revert to an incremental, dedicated network. Convergent networks offer both cost and operational efficiency, and such support is a key aspect of Cisco Powered Networks.

Beginning with Cisco Unified CCE Release 7.0 (provided that the required latency and bandwidth requirements inherent in the real-time nature of this product are satisfied), Cisco supports Unified CCE deployments in a convergent QoS-aware public network as well as in a convergent QoS-aware private network environment. This chapter presents QoS marking, queuing, and shaping recommendations for both the Unified CCE public and private network traffic.

Historically, two QoS models have been used: Integrated Services (IntServ) and Differentiated Services (DiffServ). The IntServ model relies on the Resource Reservation Protocol (RSVP) to signal and reserve the desired QoS for each flow in the network. Scalability becomes an issue with IntServ because state information of thousands of reservations has to be maintained at every router along the path. DiffServ, in contrast, categorizes traffic into different classes, and specific forwarding treatments are then applied to the traffic class at each network node. As a coarse-grained, scalable, and end-to-end QoS solution, DiffServ is more widely used and accepted. Unified CCE applications are not aware of RSVP, and the QoS considerations in this chapter are based on DiffServ.

Adequate bandwidth provisioning and implementation of QoS are critical components in the success of Unified CCE deployments. Bandwidth guidelines and examples are provided in this chapter to help with provisioning the required bandwidth.

What's New in This Chapter

Table 12-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 12-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic	Described in:
Port utilization for Public Network	Table 12-2
Private bandwidth example calculation	Example of a Private Bandwidth Calculation

Unified CCE Network Architecture Overview

Unified CCE is a distributed, resilient, and fault-tolerant network application that relies heavily on a network infrastructure with sufficient performance to meet the real-time data transfer requirements of the product. A properly designed Unified CCE network is characterized by proper bandwidth, low latency, and a prioritization scheme favoring specific UDP and TCP application traffic. These design requirements are necessary to ensure both the fault-tolerant message synchronization of specific duplexed Unified CCE nodes (Central Controller and Peripheral Gateway) as well as the delivery of time-sensitive system status data (agent states, call statistics, trunk information, and so forth) across the system. Expeditious delivery of PG data to the Central Controller is necessary for accurate call center state updates and fully accurate real-time reporting data.

In a Cisco Unified Communications deployment, WAN and LAN traffic can be grouped into the following categories:

•Voice and video traffic

Voice calls (voice carrier stream) consist of Real-Time Transport Protocol (RTP) packets that contain the actual voice samples between various endpoints such as PSTN gateway ports, Unified IP IVR Q-points (ports), and IP phones. This traffic includes voice streams of silently monitored and recorded agent calls.

•Call control traffic

Call control consists of packets belonging to one of several protocols (H.323, MGCP, SCCP, or TAPI/JTAPI), according to the endpoints involved in the call. Call control functions include those used to set up, maintain, tear down, or redirect calls. For Unified CCE, control traffic includes routing and service control messages required to route voice calls to peripheral targets (such as agents, skill groups, or services) and other media termination resources (such as Unified IP IVR ports) as well as the real-time updates of peripheral resource status.

•Data traffic

Data traffic can include normal traffic such as email, web activity, and CTI database application traffic sent to the agent desktops, such as screen pops and other priority data. Unified CCE priority data includes data associated with non-real-time system states, such as events involved in reporting and configuration updates.

This chapter focuses primarily on the types of data flows and bandwidth used between a remote Peripheral Gateway (PG) and the Unified ICM Central Controller (CC), on the network path between sides A and B of a PG or of the Central Controller, and on the CTI flows between the desktop application and CTI OS and/or Cisco Agent Desktop servers. Guidelines and examples are presented to help estimate required bandwidth and to help implement a prioritization scheme for these WAN segments.

The flows discussed encapsulate the latter two of the above three traffic groups. Because media (voice and video) streams are maintained primarily between Cisco Unified Communications Manager and its endpoints, voice and video provisioning is not addressed here.

For bandwidth estimates for the voice RTP stream generated by the calls to Unified CCE agents and the associated call control traffic generated by the various protocols, refer to the Cisco Unified Communications Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/designzone

Data traffic and other mission-critical traffic will vary according to the specific integration and deployment model used. For information on proper network design for data traffic, refer to the Network Infrastructure and Quality of Service (QoS) documentation available at

http://www.cisco.com/go/designzone

Network Segments

The fault-tolerant architecture employed by Unified CCE requires two independent communication networks. The private network (using a separate path) carries traffic necessary to maintain and restore synchronization between the systems and to allow clients of the Message Delivery Subsystem (MDS) to communicate. The public network carries traffic between each side of the synchronized system and foreign systems. The public network is also used as an alternate network by the fault-tolerance software to distinguish between node failures and network failures.

---

Note The terms public network and visible network are used interchangeably throughout this document.

---

A third network, the signaling access network, may be deployed in Unified ICM systems that also interface directly with the carrier network (PSTN) and that deploy the Hosted Unified ICM/Unified CCE architecture. The signaling access network is not addressed in this chapter.

Figure 12-1 illustrates the fundamental network segments for a Unified CCE system with a duplexed PG and a duplexed Central Controller (with sides A and B geographically separated).

Figure 12-1 Example of Public and Private Network Segments for a Unified CCE System

The following notes apply to Figure 12-1:

•The private network carries Unified ICM traffic between duplexed sides of the Central Controller or a PG pair. This traffic consists primarily of synchronized data and control messages, and it also conveys the state transfer necessary to re-synchronize duplexed sides when recovering from an isolated state. When deployed over a WAN, the private network is critical to the overall responsiveness of Cisco Unified ICM. It must meet aggressive latency requirements and, therefore, either IP-based priority queueing or QoS must be used on the private network links.

•The public network carries traffic between the Central Controller and call centers (PGs and AWs). The public network can also serve as a Central Controller alternate path, used to determine which side of the Central Controller should retain control in the event that the two sides become isolated from one another. The public network is never used to carry synchronization control traffic. Public network WAN links must also have adequate bandwidth to support the PGs and AWs at the call center. The IP routers in the public network must use either IP-based priority queuing or QoS to ensure that Unified ICM traffic classes are processed within acceptable tolerances for both latency and jitter.

•Call centers (PGs and AWs) local to one side of the Central Controller connect to the local Central Controller side via the public Ethernet, and to the remote Central Controller side over public WAN links. This arrangement requires that the public WAN network must provide connectivity between side A and side B. Bridges may optionally be deployed to isolate PGs and AWs from the Central Controller LAN segment to enhance protection against LAN outages.

•To achieve the required fault tolerance, the private WAN link must be fully independent from the public WAN links (separate IP routers, network segments or paths, and so forth). Independent WAN links ensure that any single point of failure is truly isolated between public and private networks. Additionally, public network WAN segments traversing a routed network must be deployed so that PG-to-CC (Central Controller) route diversity is maintained throughout the network. Be sure to avoid routes that result in common path selection (and, thus, a common point of failure) for the multiple PG-to-CC sessions (see Figure 12-1).

IP-Based Prioritization and QoS

For each of the WAN links in Figure 12-1, a prioritization scheme is required. Two such prioritization schemes are supported: IP-based prioritization and QoS. Traffic prioritization is needed because it is possible for large amounts of low-priority traffic to get in front of high-priority traffic, thereby delaying delivery of high-priority packets to the receiving end. In a slow network flow, the amount of time a single large (for example, 1500-byte) packet consumes on the network (and delays subsequent packets) can exceed 100 ms. This delay would cause the apparent loss of one or more heartbeats. To avoid this situation, a smaller Maximum Transmission Unit (MTU) size is used by the application for low-priority traffic, thereby allowing a high-priority packet to get on the wire sooner. (MTU size for a circuit is calculated from within the application as a function of the circuit bandwidth, as configured at PG setup.)

A network that is not prioritized correctly almost always leads to call time-outs and problems from loss of heartbeats as the application load increases or (worse) as shared traffic is placed on the network. A secondary effect often seen is application buffer pool exhaustion on the sending side, due to extreme latency conditions.

Unified ICM applications use three priorities: high, medium, and low. However, prior to QoS, the network effectively recognized only two priorities identified by source and destination IP address (high-priority traffic was sent to a separate IP destination address) and, in the case of UDP heartbeats, by specific UDP port range in the network. The approach with IP-based prioritization is to configure IP routers with priority queuing in a way that gives preference to TCP packets with a high-priority IP address and to UDP heartbeats over the other traffic. When using this prioritization scheme, 90% of the total available bandwidth should be granted to the high-priority queue

A QoS-enabled network applies prioritized processing (queuing, scheduling, and policing) to packets based on QoS markings as opposed to IP addresses. Unified ICM Release 7.0 provides marking capability of both Layer-3 DSCP and Layer-2 802.1p (using the Microsoft Windows Packet Scheduler) for private and public network traffic. Traffic marking in Unified ICM implies that configuring dual IP addresses on each Network Interface Controller (NIC) is no longer necessary because the network is QoS-aware. If the traffic is marked at the network edge instead, however, dual-IP configuration is still required to differentiate packets by using access control lists based on IP addresses. For details, see Where to Mark Traffic.

UDP Heartbeat and TCP Keep-Alive

The primary purpose of the UDP heartbeat design is to detect if a circuit has failed. Detection can be made from either end of the connection, based on the direction of heartbeat loss. Both ends of a connection send heartbeats at periodic intervals (typically every 100 or 400 milliseconds) to the opposite end, and each end looks for analogous heartbeats from the other. If either end misses 5 heartbeats in a row (that is, if a heartbeat is not received within a period that is 5 times the period between heartbeats), then the side detecting this condition assumes that something is wrong and the application closes the socket connection. At that point, a TCP Reset message is typically generated from the closing side. Loss of heartbeats can be caused by various reasons, such as: the network failed, the process sending the heartbeats failed, the machine on which the sending process resides is shut down, the UDP packets are not properly prioritized, and so forth.

There are several parameters associated with heartbeats. In general, you should leave these parameters set to their system default values. Some of these values are specified when a connection is established, while others can be specified by setting values in the Microsoft Windows 2000 registry. The two values of most interest are:

•The amount of time between heartbeats

•The number of missed heartbeats (currently hard-coded as 5) that the system uses to determine whether a circuit has apparently failed

The default value for the heartbeat interval is 100 milliseconds between the duplexed sides, meaning that one side can detect the failure of the circuit or the other side within 500 ms. Prior to Unified ICM Release 5.0, the default heartbeat interval between a central site and a peripheral gateway was 400 ms, meaning that the circuit failure threshold was 2 seconds in this case.

In Unified ICM Releases 5.0 and 6.0, as a part of the Unified ICM QoS implementation, the UDP heartbeat is replaced by a TCP keep-alive message in the public network connecting a Central Controller to a Peripheral Gateway. (An exception is that, when a Unified ICM Release 5.0 or 6.0 Central Controller talks to a PG that is prior to Release 5.0, the communication automatically reverts to the UDP mechanism.) Note that the UDP heartbeat remains unchanged in the private network connecting duplexed sites.

In Unified ICM Release 7.0, a consistent heartbeat or keep-alive mechanism is enforced for both the public and private network interface. When QoS is enabled on the network interface, a TCP keep-alive message is sent; otherwise UDP heartbeats are retained.

The TCP keep-alive feature, provided in the TCP stack, detects inactivity and in that case causes the server/client side to terminate. It operates by sending probe packets (namely, keep-alive packets) across a connection after the connection has been idle for a certain period, and the connection is considered down if a keep-alive response from the other side is not heard. Microsoft Windows 2000/2003 allows you to specify keep-alive parameters on a per-connection basis. For Unified ICM public connections, the keep-alive timeout is set to 5*400 ms, meaning that a failure can be detected after 2 seconds, as was the case with the UDP heartbeat prior to Release 5.0.

The reasons for moving to TCP keep-alive with QoS enabled are as follows:

•In a converged network, algorithms used by routers to handle network congestion conditions can have different effects on TCP and UDP. As a result, delays and congestion experienced by UDP heartbeat traffic can have, in some cases, little correspondence to the TCP connections.

•The use of UDP heartbeats creates deployment complexities in a firewall environment. The dynamic port allocation for heartbeat communications makes it necessary to open a large range of port numbers, thus defeating the original purpose of the firewall device.

HSRP-Enabled Network

In a network where Hot Standby Router Protocol (HSRP) is deployed on the default gateways that are configured on the Unified CCE servers, follow these recommendations:

•Configure the HSRP hold time (plus the associated processing delay) to be lower than five times the heartbeat interval (100 ms on the private network and 400 ms on the public network) in order to avoid ICM private network communication outage during HSRP active router switch-over.

---

Note With convergence delays that exceed private or public network outage notification, HSRP failover times can exceed the threshold by which network outage detection is made, thus causing the enterprise system to complete a failure and recovery phase. If primary and secondary designations are made in the HSRP configuration and the primary path router fails to the secondary side, HSRP will subsequently reinstate the primary path when possible, thereby leading to a second private network outage detection.

---

For this reason, configured HSRP convergence delays that approach 500 ms for the private network and 2 seconds for the public network are best not configured with primary and secondary designations to avoid the start-path reinstatement mentioned above. On the other hand, convergence delays that can be configured below the detected threshold (which thus render an HSRP failover to be transparent to the application) do not mandate a preferred path configuration. This approach is preferable. Cisco recommends keeping enabled routers symmetrical if path values and costs are identical. However, if available bandwidth and cost favor one path (and the path transition is transparent), then designation of a primary path and router is advised.

•The ICM fault-tolerance design requires the private network to be physically separate from the public network, therefore HSRP should never be configured to fail-over the private network traffic to the public network link, or vise versa.

•The bandwidth requirement for ICM should be guaranteed anytime with HSRP, otherwise the system behavior is unpredictable. For example, if HSRP is initially configured to do load sharing, there should still be sufficient bandwidth for ICM on the surviving links in the worst-case failure situations.

RSVP

Cisco Unified Communications Manager (Unified CM) 5.0 introduces support for Resource Reservation Protocol (RSVP) between endpoints within a cluster. A protocol for Call Admission Control (CAC), RSVP is used by the routers in the network to reserve bandwidth for calls.

To calculate bandwidth usage before RSVP was introduced, it was necessary for each Unified CM cluster to maintain local counts of how many active calls traversed between locations. If more than one Unified CM cluster shared the same link, it was necessary to dedicate bandwidth for each cluster, leading to inefficient use of available bandwidth.

RSVP solves this problem by tracing the path between two RSVP agents that reside on the same LAN as the phones. The RSVP agent is a software media termination point (MTP) that runs on Cisco IOS routers. The RSVP agents are controlled by Unified CM and are inserted into the media stream between the two phones when a call is made. The RSVP agent of the originating phone will traverse the network to the RSVP agent of the destination phone, and reserve bandwidth. Since the network routers keep track of bandwidth usage instead of Unified CM, multiple phone calls can traverse the same RSVP controlled link even if the calls are controlled by multiple Unified CMs.

Figure 12-2 shows a scenario in which two different Unified CM clusters provide service to phones at the same remote site. This may occur if a Unified CM cluster is assigned to handle an IP call center. In the scenario, two users at the same office are serviced by different clusters. RSVP offloads the bandwidth calculation responsibilities of Unified CM to the network routers.

Figure 12-2 Example of Different Unified CM Clusters

For more information on Unified CM RSVP, refer to the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at http://www.cisco.com/go/designzone.

Traffic Flow

This section briefly describes the traffic flows for the public and private networks.

Public Network Traffic Flow

The active PG continuously updates the Central Controller call routers with state information related to agents, calls, queues, and so forth, at the respective call center sites. This type of PG-to-Central Controller traffic is real-time traffic. The PGs also send up historical data each half hour on the half hour. The historical data is low-priority, but it must complete its journey to the central site within the half hour (to get ready for the next half hour of data).

When a PG starts, its configuration data is supplied from the central site so that it can know which agents, trunks, and so forth, it has to monitor. This configuration download can be a significant network bandwidth transient.

In summary, traffic flows from PG to Central Controller can be classified into the following distinct flows:

•High-priority traffic — Includes routing and Device Management Protocol (DMP) control traffic. It is sent in TCP with the public high-priority IP address.

•Heartbeat traffic — UDP messages with the public high-priority IP address and in the port range of 39500 to 39999. Heartbeats are transmitted at 400-ms intervals bidirectionally between the PG and the Central Controller. In Unified ICM Release 7.0, the UDP heartbeat is replaced with TCP keep-alive if QoS is enabled on the public network interface through the Unified ICM setup.

•Medium-priority traffic — Includes real-time traffic and configuration requests from the PG to the Central Controller. The medium-priority traffic is sent in TCP with the public high-priority IP address.

•Low-priority traffic — Includes historical data traffic, configuration traffic from the Central Controller, and call close notifications. The low-priority traffic is sent in TCP with the public non-high-priority IP address.

Administrative Workstations (AWs) are typically deployed at ACD sites, and they share the physical WAN/LAN circuits that the PGs use. When this is the case, network activity for the AW must be factored into the network bandwidth calculations. This document does not address bandwidth sizing for AW traffic.

Private Network Traffic Flow

Traffic destined for the critical Message Delivery Service (MDS) client (Router or OPC) is copied to the other side over the private link.

The private traffic can be summarized as follows:

•High-priority traffic — Includes routing, MDS control traffic, and other traffic from MDS client processes such as the PIM CTI Server, Logger, and so forth. It is sent in TCP with the private high-priority IP address.

•Heartbeat traffic — UDP messages with the private high-priority IP address and in the port range of 39500 to 39999. Heartbeats are transmitted at 100-ms intervals bidirectionally between the duplexed sides. In Unified ICM Release 7.0, the UDP heartbeat is replaced with TCP keep-alive if QoS is enabled on the private network interface through the Unified ICM setup.

•Medium-priority and low-priority traffic — For the Central Controller, this traffic includes shared data sourced from routing clients as well as (non-route control) call router messages, including call router state transfer (independent session). For the OPC (PG), this traffic includes shared non-route control peripheral and reporting traffic. This class of traffic is sent in TCP sessions designated as medium-priority and low-priority, respectively, with the private non-high priority IP address.

•State transfer traffic — State synchronization messages for the Router, OPC, and other synchronized processes. It is sent in TCP with a private non-high-priority IP address.

Bandwidth and Latency Requirements

The amount of traffic sent between the Central Controllers (call routers) and Peripheral Gateways is largely a function of the call load at that site, although transient boundary conditions (for example, startup configuration load) and specific configuration sizes also affect the amount of traffic. A rule of thumb that works well for Unified ICM software prior to Release 5.0 in steady-state operation is: 1,000 bytes (8 kb) of data is typically sent from a PG to the Central Controller for each call that arrives at a peripheral. Therefore, if a peripheral is handling 10 calls per second, we would expect to need 10,000 bytes (80 kb) of data per second to be communicated to the Central Controller. The majority of this data is sent on the low-priority path. The ratio of low to high path bandwidth varies with the characteristics of the deployment (most significantly, the degree to which post-routing is performed), but generally it is roughly 10% to 30%. Each post-route request generates between 200 and 300 additional bytes of data on the high-priority path. Translation routes incur per-call data flowing in the opposite direction (Central Controller to PG), and the size of this data is fully dependent upon the amount of call context presented to the desktop.

A site that has an ACD as well as a VRU has two peripherals, and the bandwidth requirement calculations should take both peripherals into account. As an example, a site that has 4 peripherals, each taking 10 calls per second, should generally be configured to have 320 kbps of bandwidth. The 1,000 bytes per call is a rule of thumb, but the actual behavior should be monitored once the system is operational to ensure that enough bandwidth exists. (Unified ICM meters data transmission statistics at both the Central Controller and PG sides of each path.)

Again, the rule of thumb and example described here apply to Unified ICM prior to Release 5.0, and they are stated here for reference purpose only. Bandwidth calculators and sizing formulas are supplied for Unified ICM 5.0 and later releases, and they can project bandwidth requirements far more accurately. See Bandwidth Requirements for Unified CCE Public and Private Networks, for more details.

As with bandwidth, specific latency requirements must be guaranteed in order for the Unified ICM to function as designed. The side-to-side private network of duplexed Central Controller and PG nodes has a maximum one-way latency of 100 ms (50 ms preferred). The PG-to-CC path has a maximum one-way latency of 200 ms in order to perform as designed. Meeting or exceeding these latency requirements is particularly important in an environment using Unified ICM post-routing and/or translation routes.

As discussed previously, Unified ICM bandwidth and latency design is fully dependant upon an underlying IP prioritization scheme. Without proper prioritization in place, WAN connections will fail. The Cisco Unified ICM support team has custom tools (for example, Client/Server) that can be used to demonstrate proper prioritization and to perform some level of bandwidth utilization modeling for deployment certification.

Depending upon the final network design, an IP queuing strategy will be required in a shared network environment to achieve Unified ICM traffic prioritization concurrent with other non-DNP traffic flows. This queuing strategy is fully dependent upon traffic profiles and bandwidth availability, and success in a shared network cannot be guaranteed unless the stringent bandwidth, latency, and prioritization requirements of the product are met.

Quality of Service

This section covers the planning and configuration issues to consider when moving to a Unified ICM QoS solution.

Where to Mark Traffic

In planning QoS, a question often arises about whether to mark traffic in Unified ICM or at the network edge. Each option has it pros and cons. Marking traffic in Unified ICM saves the access lists for classifying traffic in IP routers and switches. Additionally, when deployed with Microsoft Windows Packet Scheduler, Unified ICM supports traffic shaping and 802.1p marking. The traffic shaping functionality mitigates the bursty nature of Unified ICM transmissions by smoothing transmission peaks over a given time period, thereby smoothing network usage. The 802.1p capability, a LAN QoS handling mechanism, allows high-priority packets to enter the network ahead of low-priority packets in a congested Layer-2 network segment.

There are several disadvantages to marking traffic in Unified ICM. First, it is hard to make changes. For instance, if you want to change the marking values for the public network traffic, you have to make changes on all the PGs. For a system with more than 30 PGs, for example, all those changes would require quite a lot of work. Second, QoS trust has to be enabled on access-layer routers and switches, which could open the network to malicious packets with inflated marking levels.

In contrast, marking traffic at the network edge allows for centralized and secured marking policy management, and there is no need to enable trust on access-layer devices. A little overhead is needed to define access lists to recognize Unified ICM packets. For access-list definition criteria on edge routers or switches, see Table 12-2, Table 12-3, and Table 12-4. Do not use port numbers in the access lists for recognizing Unified ICM traffic (although they are provided in the tables for reference purposes) because port numbers make the access lists extremely complex and you would have be modify the access lists every time a new customer instance is added to the system.

---

Note A typical Unified ICM deployment has three IP addresses configured on each NIC, and the Unified ICM application uses two of them. For remote monitoring using PCAnywhere or VNC, because the port numbers are not used in the access lists, the third IP address should be used to prevent the remote monitoring traffic from being marked as the real Unified ICM traffic.

---

How to Mark Traffic

The default Unified ICM QoS markings are set in compliance with Cisco Unified Communications recommendations but can be overwritten if necessary. Table 12-2, Table 12-3, and Table 12-4 show the default markings, latency requirement, IP address, and port associated with each priority flow for the public and private network traffic respectively, where i# stands for the customer instance number. Notice that in the public network the medium priority traffic is sent with the high-priority public IP address and marked the same as the high-priority traffic, while in the private network it is sent with the non-high-priority private IP address and marked the same as the low priority traffic.

For details about Cisco Unified Communications packet classifications, refer to the Cisco Unified Communications Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/designzone

---

Note Cisco has begun to change the marking of voice control protocols from DSCP 26 (PHB AF31) to DSCP 24 (PHB CS3). However, many products still mark signaling traffic as DSCP 26 (PHB AF31). Therefore, in the interim, Cisco recommends that you reserve both AF31 and CS3 for call signaling.

---

 

Table 12-2 Public Network Traffic Markings (Default) and Latency Requirements 

Priority	Server-Side IP Address and Port	One-Way Latency Requirement	DSCP / 802.1p Marking
High	IP address: Router's high-priority public IP address TCP port: •40003 + (i# * 40) for DMP high-priority connection on A •41003 + (i# * 40) for DMP high-priority connection on B UDP port: 39500 to 39999 for UDP heartbeats if QoS is not enabled on Unified ICM	200 ms	AF31 / 3
Medium	IP address: Router's high-priority public IP address TCP port: •40017 + (i# * 40) for DMP high-priority connection on A •41017 + (i# * 40) for DMP high-priority connection on B	1,000 ms	AF31 / 3
Low	IP address: Router's non-high-priority public IP address TCP port: •40002 + (i# * 40) for DMP low-priority connection on A •41002 + (i# * 40) for DMP low-priority connection on B	5 seconds	AF11 / 1

 

Table 12-3 Router Private Network Traffic Markings (Default) and Latency Requirements 

Priority	Server-Side IP Address and Port	One-Way Latency Requirement	DSCP / 802.1p Marking
High	IP address: Router's high-priority private IP address TCP port: 41005 + (i# * 40) for MDS high-priority connection UDP port: 39500 to 39999 for UDP heartbeats if QoS is not enabled on Unified ICM	50 ms	AF31 / 3
Medium	IP address: Router's non-high-priority private IP address TCP port: 41016 + (i# * 40) for MDS medium-priority connection	1,000 ms	AF11 / 1
Low	IP address: Router's non-high-priority private IP address TCP port: •41004 + (i# * 40) for MDS low-priority connection •41022 + (i# * 40) for CIC StateXfer connection •41021 + (i# * 40) for CLGR StateXfer connection •41023 + (i# * 40) for HLGR StateXfer connection •41020 + (i# * 40) for RTR StateXfer connection	1,000 ms	AF11 / 1

 

Table 12-4 PG Private Network Traffic Markings (Default) and Latency Requirements 

Priority	Server-Side IP Address and Port	One-Way Latency Requirement	DSCP / 802.1p Marking
High	IP address: PG's high-priority private IP address TCP port: •43005 + (i# * 40) for MDS high-priority connection of PG #1 •45005 + (i# * 40) for MDS high-priority connection of PG #2 UDP port: 39500 to 39999 for UDP heartbeats if QoS is not enabled on Unified ICM	50 ms	AF31 / 3
Medium	IP address: PG's non-high-priority private IP address TCP port: •43016 + (i# * 40) for MDS medium-priority connection of PG #1 •45016 + (i# * 40) for MDS medium-priority connection of PG #2	1,000 ms	AF11 / 1
Low	IP address: PG's non-high-priority private IP address TCP port: •43004 + (i# * 40) for MDS low-priority connection of PG #1 •45004 + (i# * 40) for MDS low-priority connection of PG #2 •43023 + (i# * 40) for OPC StateXfer of PG #1 •45023 + (i# * 40) for OPC StateXfer of PG #2	1,000 ms	AF11 / 1

QoS Configuration

This section presents some QoS configuration examples for the various devices in a Unified CCE system.

Configuring QoS on Unified ICM Router and PG

The QoS setup on the Unified ICM Router and PG is necessary only if the marking will be done in the Unified ICM and will be trusted by the network. For details, refer to the Installation Guide for Cisco ICM/IPCC Enterprise & Hosted Editions, available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1001/prod_installation_guides_list.html

Configuring QoS on Cisco IOS Devices

This section presents some representative QoS configuration examples. For details about campus network design, switch selection, and QoS configuration commands, refer to the Enterprise QoS Solution Reference Network Design (SRND), available at

http://www.cisco.com/go/designzone

---

Note The terms public network and visible network are used interchangeably throughout this document.

---

---

Note The marking value, bandwidth data, and queuing policy in the examples below are provided for demonstration purpose only. Under no circumstances should you copy and paste the examples without making corresponding changes in the real working system.

---

Configuring 802.1q Trunks on IP Switches

If 802.1p is an intended feature and the 802.1p tagging is enabled on the NIC for the visible network, the switch port into which the Unified ICM server plugs must be configured as an 802.1q trunk, as illustrated in the following configuration example:

switchport mode trunk 

switchport trunk encapsulation dot1q 

switchport trunk native vlan [data/native VLAN #] 

switchport voice vlan [voice VLAN #] 

switchport priority-extend trust 

spanning-tree portfast 

Configuring QoS Trust

Assuming Unified ICM DSCP markings are trusted, the following commands enable trust on an IP switch port:

mls qos 

    interface mod/port 

        mls qos trust dscp 

Configuring Queuing Policy to Act on Marked Traffic

Using the public (visible) network as an example, the class map below identifies two marking levels, AF31 for high-priority traffic (which actually includes medium-priority public network traffic because it is marked the same as the high-priority traffic by default) and AF11 for low-priority traffic:

class-map match-all Unified ICM_Public_High

    match ip dscp af31

class-map match-all ICM_Public_Low

    match ip dscp af11

If the link is dedicated to Unified ICM Public traffic only, the policy map puts ICM_Public_High traffic into the priority queue with the minimum and maximum bandwidth guarantee of 500 kbps, and it puts ICM_Public_Low traffic into the normal queue with a minimum bandwidth of 250 kbps:

policy-map ICM_Public_Queuing 

    class ICM_Public_High 

        priority 500 

    class ICM_Public_Low 

        bandwidth 250 

You can also use the commands priority percent and bandwidth percent to assign bandwidth on a percentage basis, and 90% of the link bandwidth should be assigned to the priority queue.

If it is a shared link, then you should use the sizing tools introduced in the section on Bandwidth Provisioning, to calculate the bandwidth requirement at each priority level and add it to the allocation for non-ICM traffic in the same queue. For example, if the link is shared with Unified CM ICCS traffic and RTP traffic and they respectively require 600 kbps and 400 kbps, and if the link also carries the private traffic in case of failover and the high priority and low priority private ICM traffic respectively require 200 kbps and 100 kbps, the configuration would be:

policy-map Converged_Link_Queuing 

    class RTP 

      priority 400 

    class ICCS 

        bandwidth 600 

    class ICM_Public_High 

        bandwidth 500 

    class ICM_Public_Low 

        bandwidth 250 

    class ICM_Private_High 

        bandwidth 200 

    class ICM_Private_Low 

        bandwidth 100 

You can also use the commands priority percent and bandwidth percent to assign bandwidth on a percentage basis. If the link is dedicated to Unified ICM traffic only, 90% of the link bandwidth should be assigned to the priority queue. If it is a shared link, then you should use the sizing tools introduced in the section on Bandwidth Provisioning, to calculate the bandwidth requirement at each priority level and add it to the allocation for non-ICM traffic in the same queue.

Finally, the queuing policy is applied to the outgoing interface:

interface mod/port 

    service-policy output ICM_Public_Queuing

Configuring Marking Policy to Mark Traffic

As discussed earlier, rather than marking traffic in the Unified ICM, another option is to mark traffic at the network edge. First, define access lists to recognize Unified ICM traffic flows:

access-list 100 permit tcp host Public_High_IP any

access-list 100 permit tcp any host Public_High_IP

access-list 101 permit tcp host Public_NonHigh_IP any

access-list 101 permit tcp any host Public_NonHigh_IP

Second, classify the traffic using a class map:

class-map match-all ICM_Public_High

    match access-group 100

class-map match-all ICM_Public_Low

    match access-group 101

Third, define the marking policy using a policy map:

policy-map ICM_Public_Marking

    class ICM_Public_High

        set ip dscp af31

    class ICM_Public_Low

        set ip dscp af11

Finally, apply the marking policy to the incoming interface:

interface mod/port 

    service-policy input ICM_Public_Marking

QoS Performance Monitoring

Once the QoS-enabled processes are up and running, the Microsoft Windows Performance Monitor (PerfMon) can be used to track the performance counters associated with the underlying links. For details on using PerfMon for this purpose, refer to the ICM Administration Guide for Cisco ICM Enterprise Edition, available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1001/prod_maintenance_guides_list.html

Bandwidth Provisioning

This section discusses bandwidth provisioning consideration for the Unified CCE system.

Bandwidth Requirements for Unified CCE Public and Private Networks

This section briefly describes bandwidth sizing for the public (visible) and private networks.

Public Network Bandwidth

Special tools are available to help calculate the bandwidth needed for the following public network links:

Unified ICM Central Controller to Unified CM PG

A tool is accessible to Cisco partners and Cisco employees for computing the bandwidth needed between the ICM Central Controller and Unified CM. This tool is called the ACD/CallManager Peripheral Gateway to ICM Central Controller Bandwidth Calculator, and it is available (with proper login authentication) through the Cisco Steps to Success Portal at

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100897

Unified ICM Central Controller to Unified IP IVR or Unified CVP PG

A tool is accessible to Cisco partners and Cisco employees for computing the bandwidth needed between the ICM Central Controller and the IP IVR PG. This tool is called the VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator, and it is available (with proper login authentication) through the Cisco Steps to Success Portal at

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901

At this time, no tool exists that specifically addresses communications between the Unified ICM Central Controller and the Cisco Unified Customer Voice Portal (Unified CVP) PG. Testing has shown, however, that the tool for calculating bandwidth needed between the Unified ICM Central Controller and the Unified IP IVR PG will also produce accurate measurements for Unified CVP if you perform the following substitution in one field:

For the field labeled Average number of RUN VRU script nodes, substitute the number of Unified ICM script nodes that interact with Unified CVP.

Private Network Bandwidth

Table 12-5 is a worksheet to assist with computing the link and queue sizes for the private network. Definitions and examples follow the table.

---

Note Minimum link size in all cases is 1.5 Mbps (T1).

---

 

Table 12-5 Worksheet for Calculating Private Network Bandwidth 

Component	Effective BHCA	Multiplication Factor	Recommended Link	Multiplication Factor	Recommended Queue
Router + Logger		* 30		* 0.8		Total Router+Logger High-Priority Queue Size
Unified CM PG		* 100		* 0.9		Add these three numbers together and total in the shaded box below to get the PG High-Priority Queue size.
Unified IP IVR PG		* 60		* 0.9
Unified CVP PG		* 120		* 0.9
Unified IP IVR or Unified CVP Variables		* ((Number of Variables * Average Variable Length) / 40)		* 0.9
		Total Link Size				Total PG High-Priority Queue Size

If one dedicated link is used between sites for private communication, add all link sizes together and use the Total Link Size at the bottom of Table 12-5. If separate links are used, one for Router/Logger Private and one for PG Private, use the first row for Router/Logger requirements and the bottom three (out of four) rows added together for PG Private requirements.

Effective BHCA (effective load) on all similar components that are split across the WAN is defined as follows:

•Router + Logger

This value is the total BHCA on the call center, including conferences and transfers. For example, 10,000 BHCA ingress with 10% conferences or transfers would be 11,000 Effective BHCA.

•Unified CM PG

This value includes all calls that come through Unified ICM Route Points controlled by Unified CM and/or that are ultimately transferred to agents. This assumes that each call comes into a route point and is eventually sent to an agent. For example, 10,000 BHCA ingress calls coming into a route point and being transferred to agents, with 10% conferences or transfers, would be 11,000 effective BHCA.

•Unified IP IVR PG

This value is the total BHCA for call treatment and queuing. For example, 10,000 BHCA ingress calls, with all of them receiving treatment and 40% being queued, would be 14,000 effective BHCA.

•Unified CVP PG

This value is the total BHCA for call treatment and queuing coming through a Unified CVP. 100% treatment is assumed in the calculation. For example, 10,000 BHCA ingress calls, with all of them receiving treatment and 40% being queued, would be 14,000 effective BHCA.

•Unified IP IVR or Unified CVP Variables

This value represents the number of Call and ECC variables and the variable lengths associated with all calls routed through the Unified IP IVR or Unified CVP, whichever technology is used in the implementation.

Example of a Private Bandwidth Calculation

Table 12-6 shows an example calculation for a combined dedicated private link with the following characteristics:

•BHCA coming into the contact center is 10,000.

•100% of calls are treated by Unified IP IVR and 40% are queued.

•All calls are sent to agents unless abandoned. 10% of calls to agents are transfers or conferences.

•There are four Unified IP IVRs used to treat and queue the calls, with one PG pair supporting them.

•There is one Unified CM PG pair for a total of 900 agents.

•Calls have ten 40-byte Call Variables and ten 40-byte ECC variables.

 

Table 12-6 Example Calculation for a Combined Dedicated Private Link 

Component	Effective BHCA	Multiplication Factor	Recommended Link	Multiplication Factor	Recommended Queue
Router + Logger	11,000	* 30	330,000	* 0.8	264,000	Total Router+Logger High-Priority Queue Size
Unified CM PG	11,000	* 100	1,100,000	* 0.9	990,000	Add these three numbers together and total in the shaded box below to get the PG High-Priority Queue size.
Unified IP IVR PG	14,000	* 60	840,000	* 0.9	756,000
Unified CVP PG	0	* 120	0	* 0.9	0
Unified IP IVR or Unified CVP Variables	14,000	* ((Number of Variables * Average Variable Length) / 40)	280,000	* 0.9	252,000
		Total Link Size	2,550,000		1,998,000	Total PG High-Priority Queue Size

For the combined dedicated link in this example, the results are as follows:

•Total Link = 2,550,000 bps

•Router/Logger high-priority bandwidth queue of 264,000 bps

•PG high-priority bandwidth queue of 1,998,000 bps

If this example were implemented with two separate links, Router/Logger private and PG private, the link sizes and queues would be as follows:

•Router/Logger link of 330,000 bps (actual minimum link is 1.5 Mb, as defined earlier), with high-priority bandwidth queue of 264,000 bps

•PG link of 2,220,000 bps, with high-priority bandwidth queue of 1,998,000 bps

Bandwidth Requirements for Unified CCE Clustering Over the WAN

For details about Unified CCE clustering over the WAN, see IPT: Clustering Over the WAN, page 2-27.

Bandwidth must be guaranteed across the highly available (HA) WAN for all Unified ICM private, public, CTI, and Unified CM intra-cluster communications (ICC). Moreover, bandwidth must be guaranteed for any calls going across the highly available WAN. Minimum total bandwidth required across the highly available WAN for all Unified CCE signaling is 2 Mbps.

In addition to the bandwidth requirements for the private and public networks, this section adds bandwidth analysis for the connections from Unified IP IVR (CRS) or Unified CVP PG to Unified IP IVR (CRS) or Unified CVP, CTI Server to CTI OS, and Unified CM intra-cluster communications (ICC).

Unified IP IVR or Unified CVP PG to Unified IP IVR or Unified CVP

At this time, no tool exists that specifically addresses communication between the Unified IP IVR or Unified CVP PG and the Unified IP IVR or Unified CVP. However, the tool mentioned in the previous section produces a fairly accurate measurement of bandwidth needed for this communication. Bandwidth consumed between the Unified ICM Central Controller and Unified IP IVR or Unified CVP PG is very similar to the bandwidth consumed between the Unified IP IVR or Unified CVP PG and the Unified IP IVR or Unified CVP.

The VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator tool is available (with proper login authentication) through the Cisco Steps to Success Portal at

http://tools.cisco.com/s2slv2/ViewDocument?docName=EXT-AS-100901

If the Unified IP IVR or Unified CVP PGs are split across the WAN, total bandwidth required would be double what the tool reports: once for Unified ICM Central Controller to Unified IP IVR or Unified CVP PG and once for Unified IP IVR or Unified CVP PG to Unified IP IVR or Unified CVP.

CTI Server to CTI OS

The worst case for bandwidth utilization across the WAN link between the CTI OS and CTI Server occurs when the CTI OS is remote from the CTI Server. A bandwidth queue should be used to guarantee availability for this worst case.

For this model, the following simple formula can be used to compute worst-case bandwidth requirements:

•With no Extended Call Context (ECC) or Call Variables:

BHCA * 20 = bps

•With ECC and/or Call Variables

BHCA * (20 + ((Number of Variables * Average Variable Length) / 40) = bps

Example: With 10,000 BHCA and 20 ECC variables with average length of 40 bits:

10,000 * (20 + ((20 * 40) / 40) = 10,000 * 40 = 400,000 bps = 400 kbps

Unified CM Intra-Cluster Communications (ICC)

The Cisco Unified Communications Solution Reference Network Design (SRND) guide states that 900 kbps must be reserved for every 10,000 BHCA. This amount is significantly higher with Unified CCE due to the number of call redirects and additional CTI/JTAPI communications encompassed in the intra-cluster communications.

The bandwidth that must be reserved is approximately 2,000 kbps (2 Mbps) per 10,000 BHCA. This requirement assumes proper design and deployment based on the recommendations in this Unified CCE design guide. Inefficient design (such as "ingress calls to Site 1 are treated in Site 2") will cause additional intra-cluster communications, possibly exceeding the defined requirements.

More specifically, you can use the following formula to calculate the required bandwidth:

Link Size BHCA * 200 = bps

Bandwidth Requirements for Gateway PG to System PG

This section provides some basic guidelines for provisioning bandwidth for the connection between the gateway PG and the system PG.

Bandwidth Requirements for Unified CCE Gateway PG to Central Controller

No special considerations are necessary for the PG-to-CC connection over other TDM PGs.

If agent reporting is not used, then the Enable Agent Reporting checkbox in the Agent distribution tab of the PG explorer should be unchecked to avoid sending unnecessary data over the link. For more information, see Bandwidth and Latency Requirements.

Bandwidth Requirements for Unified CCE Gateway PG to System PG

Figure 12-3 illustrates the connection between the parent PG/PIM and the child system PG.

Figure 12-3 Connection Between Gateway PG and System PG

---

Note Cisco does not recommend deploying the gateway PG remote from the system PG that it is monitoring.

---

The following factors affect the amount of data coming over the link once it is initialized:

•Message sizes can vary depending upon their content (such as the size of extensions, agent IDs, and call data). A Route Request with no data, for example, can be a very small message. If all call variables and ECC variables are populated with large values, this will drastically affect the size of the message.

•Call scenarios can cause great variation in the number of messages per call that are transmitted over the line. A simple call scenario might cause 21 messages to be transmitted over the line. More complex call scenarios involving queuing, hold retrieves, conferences, or transfers will add greatly to the number of messages per call that are transmitted over the line.

•The more skill groups to which an agent belongs, the more messages are transmitted over the line. In a simple call scenario, each additional skill group adds two messages per call. These messages are approximately 110 bytes each, depending on field sizes.

Basic Numbers (Where to Start:)

A basic call flow (simple ACD call with no hold, retrieve, conference, or transfer) with a single skill group will be typically generate 21 messages, and you should plan a minimum of approximately 2700 bytes for the required bandwidth for it.

In a basic call flow, there are four places where call variables and ECC data can be sent. Thus, if you use call data and/or ECC variables, they will all be sent four times during the call flow. Using a lot of call data could easily increase (by double, triple, or more) the 2700 bytes of estimated bandwidth per call.

---

Note Call variables used on the child PG are transmitted to the parent PG regardless of their use or the setting of the MAPVAR parameter. For example, if call variables 1 through 8 are used on the child PG but are never referenced on the parent PG (and assume MAPVAR = EEEEEEEEEE, meaning Export all but Import nothing), they will still be transmitted to the PG where the filtering takes place, therefore bandwidth is still required. For the reverse situation, bandwidth is spared. For example, if the map setting is MAPVAR = IIIIIIIIII (Import all but Export nothing), then bandwidth is spared. Call variable data will not be transmitted to the child PG on a ROUTE_SELECT response.

---

Basic Call Flow Example

Assume a call rate of 300 simple calls per minute (5 calls per second) and the agents are all in a single skill group with no passing of call variables or ECC data. The required bandwidth in this case is:

5 * 2700 = 13,500 bytes per second = 13.5 kbps of required bandwidth

Note that a more complex call flow or a call flow involving call data could easily increase this bandwidth requirement.

Autoconfiguration

If autoconfiguration is used, it is possible that the entire agent, skill group, and route-point configuration could be transmitted from the child PG to the parent PG. If not much bandwidth is available, it could take considerable time for this data to be transmitted.

Table 12-7 lists the approximate number of bytes (worst case) that are transmitted for each of the data entities. If you know the size of the configuration on a child PG, you can calculate the total number of bytes of configuration data that will be transmitted. Note that the values in are worse-case estimates that assume transmitting only one item per record with each field having the maximum possible size (which is extremely unlikely).

 

Table 12-7 Bytes Transmitted per Data Item Under Worst-Case Conditions 

Data Item Transmitted	Size
Agent	500 bytes
Call type	250 bytes
Skill group	625 bytes
Device (route point, device target, and so forth)	315 bytes

For example, if the child PG has 100 agents, 10 call types, 5 skill groups, and 20 route points, then the amount of configuration data transmitted could be estimated as follows:

100 agents * 500 bytes = 50,000 bytes

10 call types * 250 bytes = 2,500 bytes

5 skill groups * 625 bytes = 3,125 bytes

20 route points * 315 bytes = 6,300 bytes

50,000 + 2,500 + 3,125 + 6,300 = 61,925 bytes

The total amount of data (approximate maximum) transmitted for this configuration is 61,925 bytes.

Best Practices and Options for Gateway PG and Unified CCE

To mitigate the bandwidth demands, use any combination of the following options:

•Use fewer call and ECC variables on the child PG.

Certain messages transmit call data from the child Unified CCE system to the parent. Reducing the size and quantity of variables used will reduce the data transmitted for these events. (See the Note under Basic Numbers (Where to Start:).)

•User the MAPVAR = IIIIIIIIII and MAPECC = IIIIIIIIII peripheral configuration parameters.

If you do not use the MAPVAR and MAPECC option (which means that the settings default to MAPVAR = BBBBBBBBBB and MAPECC = BBBBBBBBBB), then for every ROUTE_SELECT sent to the child, all Call and ECC variables used on the parent are also sent to the child. If you use the I (Import) or N (None) option for MAPVAR, MAPECC, or both, then the Gateway PG will not send these variables over the line to the child system. If a lot of call variables and/or ECC variables are used on the parent, these parameter settings can save some bandwidth.

---

Note Eliminating Import (I or B setting) of data does not save any bandwidth because, even though the Gateway PG does not import the data, the child Unified CCE system still transmits it.

---

Bandwidth Requirements and QoS for Agent and Supervisor Desktops

There are many factors to consider when assessing the traffic and bandwidth requirements for Agent and Supervisor Desktops in a Unified CCE environment. While the VoIP packet stream bandwidth is the predominant contributing factor to bandwidth, other factors such as call control, agent state signaling, silent monitoring, recording, and statistics must also be considered.

VoIP packet stream bandwidth requirements are derived directly from the voice codec deployed (G.729, G.711, and so forth), and can range from 4 kbps to 64 kbps per voice stream. Therefore, the contact center's call profile must be well understood because it defines the number of straight calls (incoming or outgoing), consultative transfers, and conference calls, and consequently the number of VoIP packet streams, that are active on the network. In general, the number of VoIP packet streams will be typically slightly greater than one per agent, to account for held calls, silent monitoring sessions, active recordings, consultative transfers, and conference calls.

Call control, agent state signaling, silent monitoring, recording, and statistics bandwidth requirements can collectively represent as much as 25% to 50% of total bandwidth utilization. While VoIP packet stream bandwidth calculations are fairly straightforward, these other factors depend heavily upon implementation and deployment details and are therefore discussed further in the sections below.

Because WAN links are usually the lowest-speed circuits in an Cisco Unified Communications network, attention must be given not only to bandwidth, but also to reducing packet loss, delay, and jitter where voice traffic is sent