-
Cisco Unified Contact Center Enterprise 7.0, 7.1, and 7.2 Solution Reference Network Design (SRND)
-
Preface
-
Architecture Overview
-
Deployment Models
-
Design Considerations for High Availability
-
Unified Contact Center Enterprise Desktop
-
Cisco Unified Outbound Option
-
Cisco Unified Mobile Agent
-
Cisco Unified Expert Advisor Option
-
Securing Unified CCE
-
Sizing Call Center Resources
-
Sizing Unified CCE Components and Servers
-
Sizing Cisco Unified Communications Manager Servers
-
Bandwidth Provisioning and QoS C
-
Glossary
-
Index
-
Table Of Contents
Bandwidth Provisioning and QoS Considerations
Unified CCE Network Architecture Overview
IP-Based Prioritization and QoS
UDP Heartbeat and TCP Keep-Alive
Bandwidth and Latency Requirements
Configuring QoS on Unified ICM Router and PG
Configuring QoS on Cisco IOS Devices
Bandwidth Requirements for Unified CCE Public and Private Networks
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
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
Bandwidth Requirements for Cisco E-Mail Manager
Bandwidth and Latency Requirements for the User List Tool
Bandwidth Provisioning and QoS Considerations
Last revised on: August 18, 2009
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.
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 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 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/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
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 Cisco Enterprise QoS Solution Reference Network Design Guide, available at
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
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
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:
•
•
•
•
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 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:
•
•
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:
•
Note
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.
•
•
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/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
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:
•
•
•
•
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:
•
•
•
•
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
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/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
Note
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/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
Note
Note
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 trunkswitchport trunk encapsulation dot1qswitchport trunk native vlan [data/native VLAN #]switchport voice vlan [voice VLAN #]switchport priority-extend trustspanning-tree portfastConfiguring QoS Trust
Assuming Unified ICM DSCP markings are trusted, the following commands enable trust on an IP switch port:
mls qosinterface mod/portmls qos trust dscpConfiguring 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_Highmatch ip dscp af31class-map match-all ICM_Public_Lowmatch ip dscp af11If 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_Queuingclass ICM_Public_Highpriority 500class ICM_Public_Lowbandwidth 250You 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_Queuingclass RTPpriority 400class ICCSbandwidth 600class ICM_Public_Highbandwidth 500class ICM_Public_Lowbandwidth 250class ICM_Private_Highbandwidth 200class ICM_Private_Lowbandwidth 100You 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/portservice-policy output ICM_Public_QueuingConfiguring 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 anyaccess-list 100 permit tcp any host Public_High_IPaccess-list 101 permit tcp host Public_NonHigh_IP anyaccess-list 101 permit tcp any host Public_NonHigh_IPSecond, classify the traffic using a class map:
class-map match-all ICM_Public_Highmatch access-group 100class-map match-all ICM_Public_Lowmatch access-group 101Third, define the marking policy using a policy map:
policy-map ICM_Public_Markingclass ICM_Public_Highset ip dscp af31class ICM_Public_Lowset ip dscp af11Finally, apply the marking policy to the incoming interface:
interface mod/portservice-policy input ICM_Public_MarkingQoS 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
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:
•
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.
•
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.
•
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.
•
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.
•
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:
•
•
•
•
•
•
For the combined dedicated link in this example, the results are as follows:
•
•
•
If this example were implemented with two separate links, Router/Logger private and PG private, the link sizes and queues would be as follows:
•
•
When using Multilink Point-to-Point Protocol (MLPPP) for private networks, Cisco recommends the following attributes for the MLPPP link:
•
•
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-28.
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 or Unified CVP PG to Unified IP IVR 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:
•
BHCA * 20 = bps
•
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 Communication Signaling (ICCS)
The bandwidth required for Intra-Cluster Communication Signaling (ICCS) between Unified CM subscriber nodes is significantly higher when Unified CCE is deployed, due to the number of call redirects and additional CTI/JTAPI communications encompassed in the intra-cluster communications. The following formulae may be used to calculate the required bandwidth for the ICCS and database traffic between Unified CM subscriber nodes when they are deployed with Unified CCE.
•
–
BHCA * 200 = bps
This is the bandwidth required between each Unified CM subscriber that is connected to voice gateways, agent phones, and Agent PGs.
–
644 kbps for each subscriber remote from the publisher.
•
–
Total Bandwidth (Mbps) = ((Total BHCA) / 10,000) * [2.25 + (0.006 * Delay)], where Delay = Round-trip-time delay in msec
This is the bandwidth required between each Unified CM subscriber that is connected to voice gateways, agent phones, and Agent PGs.
–
1.544 Mbps for each subscriber remote from the publisher
The BHCA value to use for the ICCS formulae above is the total BHCA for all calls coming into the contact center.
These bandwidth requirements assume proper design and deployment based on the recommendations contained throughout this document. Inefficient design (for example, if ingress calls to Site 1 are treated in Site 2) will cause additional intra-cluster communications, possibly exceeding the defined bandwidth requirements.
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
The following factors affect the amount of data coming over the link once it is initialized:
•
•
•
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
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).
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:
•
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:).)
•
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
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 across these links. G.729 is the preferred codec for use over the WAN because the G.729 method for sampling audio introduces the least latency (only 30 ms) in addition to any other delays caused by the network. The G.729 codec also provides good voice quality with good compression characteristics, resulting in a relatively low (8 kbps) bandwidth utilization per stream.
System architects should also consider the following QoS factors:
•
•
•
•
•
Bandwidth Requirements for CTI OS Agent Desktop
This section addresses the traffic and bandwidth requirements between CTI OS Agent Desktop and the CTI OS server. These requirements are important in provisioning the network bandwidth and QoS required between the agents and the CTI OS server, especially when the agents are remote over a WAN link. Even if the agents are local over Layer 2, it is important to account for the bursty traffic that occurs periodically because this traffic presents a challenge to bandwidth and QoS allocation schemes and can impact other mission-critical traffic traversing the network.
CTI-OS Client/Server Traffic Flows and Bandwidth Requirements
CTI OS Release 7.0 enhances the CTI OS Server/Client bandwidth in two ways:
•
•
The network bandwidth requirements increase linearly as a function of agent skill group membership. The skill group statistics are the most significant sizing criterion for network capacity, while the effect of system call control traffic is a relatively small component of the overall network load. A new feature, CTI OS Security, was introduced in CTI OS 7.0, and it affects the network load as well. When CTI OS Security is enabled (turned On), the bandwidth requirement increases significantly due to the OpenSSL overhead.
Table 12-8 shows the type of messaging of each CTI OS application.
Silent Monitoring Bandwidth Usage
Silent Monitoring provides supervisors with a means of listening in on agent calls in Unified CCE call centers that use CTI OS. Voice packets sent to and received by the monitored agent's IP hardware phone are captured from the network and sent to the supervisor desktop. At the supervisor desktop, these voice packets are decoded and played on the supervisor's system sound card.
Silent Monitoring of an agent consumes roughly the same network bandwidth as an additional voice call. If a single agent requires bandwidth for one voice call, then the same agent being silent-monitored would require bandwidth for two concurrent voice calls.
To calculate the total network bandwidth required for your call load, you would then multiply the number of calls by the per-call bandwidth figure for your particular codec and network protocol.
CTI OS Server Bandwidth Calculator
CTI OS provides a bandwidth calculator that examines the CTI OS Server-to-CTI OS Desktop bandwidth, as illustrated in Figure 12-4. It calculates Total bandwidth, agent bandwidth, and supervisor bandwidth requirements with CTI OS Security turned on or off. Additional information about the CTI OS Bandwidth Calculator is available at
http://www.cisco.com/en/US/products/sw/custcosw/ps14/prod_technical_reference_list.html
Figure 12-4 CTI OS Server-to-CTI OS Desktop Communication
Best Practices and Options for CTI OS Server and CTI OS Agent Desktop
To mitigate the bandwidth demands, use any combination of the following options:
Configure Fewer Statistics
CTI OS allows the system administrator to specify, in the registry, the statistics items that are sent to all CTI OS clients. The choice of statistics affects the size of each statistics packet and, therefore, the network traffic. Configuring fewer statistics will decrease the traffic sent to the agents. The statistics cannot be specified on a per-agent basis at this time. For more information on agent statistics, refer to the CTI OS System Manager's Guide, available at
http://www.cisco.com/en/US/products/sw/custcosw/ps14/prod_installation_guides_list.html
Turn Off Statistics on a Per-Agent Basis
You can turn off statistics on a per-agent basis by using different connection profiles. For example, if Unified MAs use a connection profile with statistics turned off, these client connections would have no statistics traffic at all between the CTI OS Server and the Agent or Supervisor Desktop. This option could eliminate the need for a separate CTI OS Server in remote locations.
A remote supervisor or selected agents might still be able to log statistics by using a different connection profile with statistics enabled, if more limited statistics traffic is acceptable for the remote site.
In the case where Unified MAs have their skill group statistics turned off but the supervisor would like to see the agent skill group statistics, the supervisor could use a different connection profile with statistics turned on. In this case, the volume of traffic sent to the supervisor would be considerably less. For each skill group and agent (or supervisor), the packet size for a skill-group statistics message is fixed. So an agent in two skill groups would get two packets, and a supervisor observing five skill groups would get five packets. If we assume 10 agents at the remote site and one supervisor, all with the same two skill groups configured (in Unified CCE, the supervisor sees all the statistics for the skill groups to which any agent in his agent team belongs), then this approach would reduce skill-group statistics traffic by 90% if only the supervisor has statistics turned on to observe the two skill groups but agents have statistics turned off.
Also, at the main location, if agents want to have their skill-group statistics turned on, they could do so without impacting the traffic to the remote location if the supervisor uses a different connection profile. Again, in this case no additional CTI OS servers would be required.
In the case where there are multiple remote locations, assuming only supervisors need to see the statistics, it would be sufficient to have only one connection profile for all remote supervisors.
Turn Off All Skill Group Statistics in CTI OS
If skill group statistics are not required, turn them all off. Doing so would remove the connections between the CTI OS Server and the Agent or Supervisor Desktop and would eliminate all statistics traffic.
Bandwidth Requirements for Cisco Agent Desktop
This section presents some design considerations for provisioning network bandwidth, providing security and access to corporate data stores, and ensuring Quality of Service (QoS) for Unified CCE installations that include the Cisco Agent Desktop (CAD) product.
Silent Monitoring Bandwidth Usage
The silent monitoring feature of the CAD desktop software, which includes listening to a live call, recording an agent call, and listening to a recorded call, has the largest bandwidth requirements for the CAD product. Properly configuring this feature is especially important for Unified MAs who are connected to the main site by a WAN connection.
To access the silent monitoring feature, a request is sent to a VoIP provider. The VoIP provider captures from the network, or reads from disk, the voice streams representing the call (two voice streams per call) and sends them back to the requestor. The requestor receives the streams and either decodes them for listening or stores them to disk. The bandwidth requirements detailed in this section are for the network links between the requestor and provider.
Silent Monitoring Requestors
There are two possible requestors in the CAD software:
•
•
Cisco Supervisor Desktops will send silent monitor requests when the supervisor wishes to listen to an agent's call in real-time or listen to a call that was recorded earlier. The Recording and Playback service will send recording requests when a supervisor or agent wishes to record a call. For listening to or recording a live call, the VoIP provider will capture the voice streams and send them to the requestor. On the supervisor's desktop, these streams are decoded and played through the supervisor's desktop sound card. For recording, the Recording and Playback service receives the voice streams and saves them to disk.
A Unified CCE installation may have one or two Recording services.
Silent Monitoring Providers
There are three possible VoIP providers in the CAD software:
•
•
•
The Cisco Agent Desktop application contains a module referred to as the Desktop Monitor service that runs on the agent's desktop. It is responsible for processing silent monitoring requests only for the agent logged into the CAD application on the desktop. It captures voice packets sent to the phone or IP Communicator software phone associated with the logged-in agent. The phone must be a Cisco Unified IP Phone 7910, 7940, 7960, or 7970 connected in series with the agent desktop on the network. These phones are supported because they contain an additional network port that allows the phone to be connected to a network and also to an agent's computer. They also support the ability of hubs and switches to propagate network traffic through this additional port. This capability is what allows the Desktop Monitor service to see the phone conversations on the agent's phone.
By default, this service is active on all agent desktops when the application is started. After initial installation of the CAD servers, all agents are already configured to use the Desktop Monitor service for the silent monitoring feature.
A VoIP Monitor service is able to handle multiple requests for silent monitoring simultaneously. It captures packets directly from the switch via the switch's Switched Port Analyzer (SPAN) configuration. An installation may have up to five VoIP Monitor services on different machines. Off-board VoIP services may be installed at remote office locations. In some instances, this service may be required due to network complexity and capacity planning. Agents must be explicitly configured to use a VoIP Monitor service if this is the method desired for silently monitoring for that agent's device.
Note
The Recording and Playback service may also provide the two streams representing a phone call when a supervisor plays back a recorded agent call. In this case, the streams have already been stored on disk from an earlier recording session. The Recording and Playback service reads the raw data files from the disk and sends the RTP streams over the network to the supervisor's desktop, where they are played through the sound card.
As this description indicates, the Recording and Playback service may be either the requestor (for recording a live call) or a provider (for playing back a recorded call).
A VoIP and Recording and Playback service are usually installed along with the CAD base services. Additional VoIP services and a second Recording and Playback service may be installed on other boxes.
Figure 12-5 shows a representative Unified CCE installation supporting a remote office over a WAN. Both the main office and the remote office have a VoIP Monitor service on-site.
Figure 12-5 VoIP Monitor Service at Main and Remote Sites
When you locate the requestors and providers, you can determine where the bandwidth will be required for the silent monitoring feature. The following notes regarding bandwidth apply to Figure 12-5:
•
•
Regardless of who is the requestor and VoIP provider, the bandwidth requirement between these two points is the bandwidth of the IP call being monitored and/or recorded. For purposes of calculating total bandwidth, you can think of each monitoring/recording session as being a new phone call. Therefore, to calculate bandwidth to support the Silent Monitoring feature, you can use the same calculations used to provision the network to handle call traffic, with the exception that the voice stream provided by the VoIP provider consists of two streams in the same direction. Whereas a normal IP phone call will have one stream going to the phone and one stream coming from the phone, the VoIP provider will have both streams coming from the provider. Keep this difference in mind when provisioning upload and download speeds for your WANs.
To determine the bandwidth requirements for these voice streams, refer to the Cisco Unified Communications Solution Reference Network Design (SRND) guide, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html
Cisco Agent Desktop Applications Bandwidth Usage
The CAD desktop applications include:
•
•
•
•
These applications also require a certain amount of bandwidth, although far less than the silent monitoring feature. In addition, the type of communication across the network is bursty. In general, bandwidth usage is low when the agents are not performing any actions. When features or actions are requested, the bandwidth increases for the time it takes to perform the action, which is usually less than one second, then the bandwidth usage drops to the steady-state level. From a provisioning standpoint, one must determine the probability of all the CAD agents performing a particular action at the same time. It might be more helpful to characterize the call center and determine the maximum number of simultaneous actions (in the worst case) to determine instantaneous bandwidth requirements, then determine what amount of delay is tolerable for a percentage of the requested actions.
For example, the raw bandwidth requirement for 1,000 CAD agents logging in simultaneously is about 6.4 kilobytes per second and the login time is about 9 seconds (with no network delay) for each agent. If the WAN link did not have this much bandwidth, logins would take longer as packets were queued before being sent and received. If this queuing delay caused the login attempts to take twice as long (18 seconds in this case), would this delay be acceptable? If not, more bandwidth should be provisioned.
Each of these applications communicates with the base CAD services running on server machines. In addition, the agent desktop application communicates with the CTI server through the CTI OS server for call control actions and state changes. Table 12-9 lists the types of messaging for each application.
Cisco Agent Desktop Bandwidth Usage
CAD agents are able to log in and log off, change their agent state, handle calls, and send reporting information to the base servers. The bandwidth requirements for these activities are fairly small but can add up when many agents are considered.
Table 12-10 shows the average bandwidth requirements for various numbers of agents. This information is derived from bandwidth testing and extrapolation of bandwidth data. Because there are many variables that can affect bandwidth, a configuration that resulted in higher bandwidth usage was chosen to provide near worst-case scenarios. If the agent's WAN link meets or exceeds the bandwidth requirements shown in this table, Cisco Agent Desktop will be able to run without delays in message passing.
The following configuration parameters affect bandwidth and apply to both Table 12-10 and Table 12-11:
•
•
•
•
•
•
•
•
•
Note that the bandwidth requirements shown do not include the bandwidth of the RTP streams for the call, recording, or monitoring sessions, but include only the messaging needed to start and stop the sessions.
Cisco Supervisor Desktop Bandwidth Usage
A Cisco Supervisor Desktop receives events for all the agents of the team that the supervisor is logged into. This information includes state changes, call handling, login/logoff, and so forth. The more agents, skills, and calls there are, the more data will be sent to supervisors. In addition, particular reports are automatically refreshed periodically to provide real-time data while the supervisor is viewing the report. Refreshing reports requires additional bandwidth.
Table 12-11 uses the same basic configuration parameters used to determine the bandwidth numbers in Table 12-10. Additional parameters include:
•
Cisco Desktop Administrator Bandwidth Usage
The bandwidth requirements for Cisco Desktop Administrator are very small and are seen only when an administrator is actively changing configurations. In general, the bandwidth used by Cisco Desktop Administrator is negligible from a provisioning standpoint.
Cisco Desktop Monitoring Console Bandwidth Usage
The bandwidth requirements for the Cisco Desktop Monitoring Console are very small and short-lived. In general, the bandwidth used by the Cisco Desktop Monitoring Console is negligible from a provisioning standpoint.
Best Practices and Recommendations for Cisco Agent Desktop Service Placement
In a Unified ICM installation using Cisco Agent Desktop, the CAD services other than the VoIP Monitor Service and the Recording and Playback services should be co-resident with the PG. As described below, the VoIP Monitor Service and Recording and Playback services may be installed on other servers.
It is possible to have up to five VoIP Monitor Servers in a CAD installation. Only one VoIP Monitor service may exist on a single server. You may install a VoIP Monitor service on the PG with or without the other CAD base services.
The main load on a VoIP Monitor service is not the number of simultaneous monitoring/recording sessions, but rather the amount of network traffic being sent to the VoIP service for the devices assigned to that VoIP service. When Switched Port Analyzer (SPAN) is configured to send traffic from a device to a particular VoIP service, that traffic (voice and perhaps data as well) is being sniffed by the VoIP services packet sniffer. This traffic is being sniffed even if there are no monitoring or recording sessions active. For this reason, there is a limit to the number of devices that can be assigned to a particular VoIP service.
If a VoIP service is running co-resident with the base CAD services, it will support the network traffic of up to 100 agents. If there are more than 100 agents configured to use a single VoIP service, that service must be moved to a separate server. A single VoIP Monitor service installed this way can handle the network traffic of 400 agents. A single VoIP Monitor service can handle up to 58 simultaneous silent monitoring/recording sessions. Adding more VoIP Monitor services increases the monitoring/recording capacity of the installation.
A single CAD installation can support one or two Recording and Playback services. Like the VoIP Monitor service, only one of these services can exist on a single computer. A Recording and Playback service may be installed co-resident on the PG with or without the CAD base services. If installed on the PG, a Recording and Playback service can support up to 32 simultaneous recording sessions. If more are required, the Recording and Playback service should be moved to a separate server (although it may coexist with an off-board VoIP Monitor service). An off-board Recording and Playback service can support up to 80 simultaneous recordings.
A second Recording and Playback service will not increase the recording capacity, but a second Recording and Playback server does provide load balancing and redundancy to the installation.
Bandwidth Requirements for a Distributor AW with HDS and Reporting
Figure 12-6 and Figure 12-7 highlight the areas of bandwidth interest for standard and large reporting deployments.
Figure 12-6 Reporting for Standard-Size Deployments
Figure 12-7 Reporting for Large Deployments
Calculating bandwidth requirements for servers that have only one network interface card (NIC) requires adding the totals for each link entering the system. For example, for a standard reporting deployment with an Administrative Workstation (AW), an Historical Data Server (HDS), and one NIC, you would calculate the required bandwidth as follows:
Total bandwidth for reporting = Report data bandwidth + Reports bandwidth
However, for a large reporting deployment, the bandwidth is calculated as follows:
Total bandwidth for reporting = Report data bandwidth + WebView sever bandwidth
Note
The following sections describe the calculations necessary to determine bandwidth requirements for each network path shown in Figure 12-6 and Figure 12-7.
Report Data Bandwidth
The factors that affect the bandwidth between the Central Controller and a Distributor AW with an HDS are calls per second (cps), the number of agents, and the use of Extended Call Context (ECC) variables. Test result indicate the following general guidelines:
•
•
•
Unified CCE provides a bandwidth calculator that aids in determining the bandwidth requirements for report data. This calculator is available at
http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_technical_reference_list.html
WebView Server Bandwidth
WebView bandwidth becomes a factor only in large reporting deployments where the WebView servers are not co-resident with the Distributor AW.
If WebView is deployed on separate servers, some configurations support up to four WebView Servers per Distributor AW with an HDS. For more specific information on the number of supported WebView servers, refer to the Hardware & System Software Specification (Bill of Materials) for Cisco ICM/ICC Enterprise & Hosted Editions, available at
The factor that affects the bandwidth between the Distributor AW and a WebView server is the total amount of reporting users that connect to the WebView server(s). Test results indicate that 50 reporting users require approximately 314,573 bytes per second. A reporting user is defined as someone running:
•
•
–
–
Unified CCE provides a bandwidth calculator that aids in determining the bandwidth requirements for the WebView server. This calculator is available at
http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_technical_reference_list.html
Reports Bandwidth
The factors that affect the bandwidth between the WebView server and WebView clients are the number of reporting users and whether Secure Socket Layer (SSL) is set to full-encryption mode. Test results indicate that for every 50 reporting users, bandwidth consumption is approximately 524,288 bytes per second, and full SSL encryption adds approximately 2,097 bytes per second.
Unified CCE provides a bandwidth calculator that aids in determining the bandwidth requirements for reports. This calculator is available at
http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_technical_reference_list.html
Bandwidth Requirements for Cisco E-Mail Manager
Cisco E-Mail Manager communicates with a distributor AW for the following purposes:
•
•
•
•
Due to the high bandwidth requirements between these two components, Cisco recommends that they be deployed on the same LAN segment.
Bandwidth and Latency Requirements for the User List Tool
In deployments in which a client AW is remote (connected over a WAN) from the domain controller and distributor AW, specific network bandwidths and latencies are required to achieve reasonable performance in the User List Tool. Reasonable performance is defined as less than 30 seconds to retrieve users. This information is provided in an effort to set expectations and to encourage upgrading to Cisco Unified CCE and ICM 7.2(3) or later releases. In this version, changes were made to enhance the performance of the tool under these conditions.
There are a number of other things that can be done to improve performance of the User List Tool. Moving a distributor AW and a domain controller local to the client AW can greatly enhance performance, as shown by the LAN row in Table 12-12. Improving the latency in your WAN connection will improve performance, and increasing the bandwidth of your WAN connection will also improve performance.
The following data points describe scenarios in which the User List Tool can retrieve users within 30 seconds in Unified CCE 7.2(3) or later releases. If you are using an earlier version of Unified CCE and are experiencing significantly slower retrieval times, consider upgrading to Unified CCE 7.2(3) or later releases. Additionally, laboratory testing has determined that the tool cannot perform reasonably for any number of users on networks with a one-way latency greater than 50 ms.
