Proper sizing of your Cisco Unified Contact Center Enterprise (Unified CCE) solution is important for optimum system performance and scalability. Sizing considerations include the number of agents the solution can support, the maximum busy hour call attempts (BHCA), and other variables that affect the number, type, and configuration of application servers required to support the deployment. Regardless of the deployment model chosen, Unified CCE is based on a highly distributed architecture, and questions about capacity, performance, and scalability apply to each element within the solution as well as to the overall solution.
This chapter presents design practices focusing on scalability and capacity for Unified CCE deployments. The design considerations and capacities presented in this chapter are derived primarily from testing and, in other cases, extrapolated test data. This information is intended to enable you to size and provision Unified CCE solutions appropriately.
This chapter refers to sizing tools that are available online. The sizing tools are available to Cisco internal employees and Cisco partners only, and proper login authentication is required.
When sizing Unified
CCE deployments, Cisco Unified Communications components are a critical factor
in capacity planning. Good design, including multiple Cisco Unified
Communications Managers and clusters, must be utilized to support significant
call loads. For additional information about Cisco Unified Communications
Manager capacity and sizing of Cisco Unified Communications components, see the
latest version of the
Cisco Unified Communications
Solution Reference Network Design Guide at
because of varying agent and skill group capacities, consider proper sizing of
the Agent PG, including Finesse and CTI OS Desktop servers, together with the
Cisco Unified Communications components.
remaining Unified CCE components, while able to scale extremely well, are
affected by specific configuration element sizing variables that also have an
impact on the system resources. These factors, discussed in this section, must
be considered and included in the planning of any deployment.
explicitly noted, the capacity information presented in
Conditions specifies capacity for inbound calls only and does not apply
equally to all implementations of Unified CCE. The data is based on testing in
particular scenarios, and it represents the maximum allowed configuration. This
data, along with the sizing variables information in this chapter, serves only
as a guide. As always, be conservative when sizing and plan for growth.
considerations are based on capacity and scalability test data. Major Unified
CCE software processes were run on individual VMs to measure their specific CPU
and memory usage and other internal system resources. Reasonable extrapolations
were used to derive capacities for co-resident software processes and multiple
vCPU VMs. This information is meant as a guide for determining when Unified CCE
software processes can be co-resident within a single VM and when certain
processes need their own dedicated VM.
Table 1 assumes that the deployment
scenario includes two fully redundant VMs.
The sizing information presented in this chapter is based on the following operating conditions:
Maximum of 30 busy hour call attempts (BHCA) per agent.
Five skill groups or precision queues per agent.
The total number of agents indicated in the following tables and figures consists of 90% agents and 10% supervisors. For example, if a table or figure indicates 100 agents, the assumption is that there are 90 agents and 10 supervisors.
Supervisors do not handle calls.
Total number of teams is equal to 10% of total number of agents.
Team members consist of 90% agents and 10% supervisors.
Call types consist of 85% straight calls, 10% consultative transfers, and 5% consultative conferences.
The default refresh rate for skill group updates is 10 seconds.
The default number of skill group statistics columns configured at the CTI OS server is 17 columns.
Agent Statistics is turned ON.
The default number of agent statistics columns configured at the CTI OS server is 6 columns.
Average of five Voice Response Unit (VRU) scripts, running consecutively in the Unified CCE script, per VRU call.
Five Expanded Call Context (ECC) scalars.
Transport Layer Security (TLS) for CTI OS is turned OFF.
No mobile agents.
Outbound hit rate is averaged at 30%.
The following notes apply to all figures and tables in this topic:
The number of agents indicates the number of logged-in agents
APG = Agent Peripheral Gateway
PGR = Lab deployment
RGR = Rogger
Figure 1. Minimum Servers Required for Unified CCE Deployments with CTI OS Desktop
The following notes apply to the figure above:
Sizing is based on the information listed above.
Voice Response Unit (VRU), Administration & Data Server, and Unified Communications Manager components are not shown.
The terms Rogger and Central Controller are used interchangeably throughout this chapter.
Table 1 Sizing Information for Unified CCE Components and Servers
Use the number of ports instead of agent count. Average of 5 Run VRU Script Nodes per call.
Agent PG with Outbound Voice (Includes Dialer and Media Routing PG)
To determine the maximum inbound agent capacity, see the Inbound Agent PG entry in this table. The capacity depends on your Unified CCE software release, hardware server class, and agent desktop type.
Impact of Outbound Option on agent capacity:
For SIP Dialers: (Maximum PG agent capacity) – (1.33 x [number of SIP Dialer ports])
For SCCP Dialers: (Maximum PG agent capacity) – (4 x [number of SCCP dialer ports])
The formula is an indicator of platform capacity. The formula does not indicate outbound resources in terms of how many agents can be kept busy by the number of dialer ports in the deployment. A quick but inexact estimate is that two ports are required for each outbound agent, but
your outbound resources can vary depending on hit rate, abandon limit, and talk time for the campaigns in the deployment. Use the sizing tool to determine outbound resources required for your campaigns.
Example: Agent PG with Cisco Finesse and 30 SIP Dialer ports.
Available inbound Finesse agents = 2000 - (1.33*30) = 1960.
The Cisco Media Blender is not supported when installed on a PG system.
Cisco Unified Web and E-Mail Interaction Manager
For the most current server specifications and sizing guidelines for Cisco Unified Web and E-Mail Interaction Manager, see the latest
Cisco Unified Customer Voice Portal (CVP) Application Server And Voice Browser
Many variables in
the Unified CCE configuration and deployment options can affect the hardware
requirements and capacities. This section describes the major sizing variables
and how they affect the capacity of the various Unified CCE components.
Busy Hour Call
The number of
calls attempted during a busy hour is an important metric. As BHCA increases,
there is an increase in the load on all Unified CCE components, most notably on
Unified CM, Unified IP IVR, and the Unified CM PG. The capacity numbers for
agents assume up to 30 calls per hour per agent. If a deployment requires more
than 30 calls per hour per agent, it will decrease the maximum number of
supported agents for the agent PG. Handle such occurrences on a case-by-case
The number of
agents is another important metric that will impact the performance of most
Unified CCE server components, including Unified CM clusters.
Groups or Precision Queues per Agent
The number of
skill groups or precision queues per agent (which is independent of the total
number of skills per system) has significant effects on the CTI OS and Finesse
servers, the Agent PG, and the Call Router and Logger. Limit the number of
skill groups and precision queues per agent to 5 or fewer, when possible, and
periodically remove unused skill groups or precision queues so that they do not
affect system performance. You can also manage the effects on the CTI OS Server
by increasing the value for the frequency of statistical updates.
The Finesse server
does not display statistics for unused skill groups. Therefore, the number of
skill groups that are assigned to agents impacts the performance of the Finesse
server more than the total number of skill groups configured. The Finesse
server supports a maximum of 1961 skill groups assigned to agents, not
including the default skill group.
group) statistics are updated on the Finesse Desktop at 10-second intervals.
The Finesse Desktop also supports a fixed number of queue statistics fields.
These fields cannot be changed.
The first table
below shows examples of how the number of skill groups or precision queues (PQ)
per agent can affect the capacity of the Unified CCE system. The table shows
the capacity for each CTI OS instance. The Finesse server supports the same
number of agents and skill groups as CTI OS. The Finesse server supports a
maximum of 50 unique skill groups across all agents on a supervisor’s team,
including the supervisor’s own skill groups. If this number is exceeded, all
skill groups monitored by the supervisor still appear on the Finesse Desktop.
However, exceeding this number may cause performance issues and is not
queue that you configure creates a skill group per Agent PG and counts towards
the supported number of skill groups per PG.
The numbers in
this table are subject to specific hardware and software requirements.
Table 2 Sizing Effects
of Skill Groups/Precision Queues for each Agent (12,000 agents)
Avg Configured PQ or SG for each Agent
Generic PG Limits
Concurrent Agent for each System
Concurrent Agent for each PG
Configured PQ or SG for each PG
Configured VRU Ports for each PG
Configured VRU PIMs for each PG
CTI OS monitor
mode applications are supported only at 20 or lower skill groups per agent.
The number of
supervisors and team members can also be a factor impacting the CTI OS Server
performance. Distribute your agents and supervisors across multiple teams and
have each supervisor monitor only a small number of agents.
can monitor only agents within their own team, all of whom must be configured
on the same peripheral.
You can add a
maximum of 50 agents per team.
You can add a
maximum of 10 supervisors per team.
A Unified CCE
support a maximum of 50 agents per supervisor with assumptions below. If a
particular environment requires more than 50 agents per supervisor, then use
the following formula to ensure that there is no impact to the CTI OS Server
and Supervisor desktop. The most important factor in this calculation is the
number of updates per second.
X = (Y * (N + 1) / R) + ((Z * N * A) / 3600), rounded up to the next integer
X = Number of updates per second received by the CTI OS Supervisor desktop.
Y = Weighted Average of Number of Skill Groups or Precision Queues per Agents. For example, if total of 10 agents have the following skill group distribution: 9 have 1 skill group and 1 agent has 12 Skill Groups. The number of skills per agent ('Y') is, Y = 90% * 1 + 10% * 12 = 2.1.
(Note that the number of configured statistics in CTI OS server is 17.)
Z = Calls per hour per agent.
A = Number of agent states. (Varies based on call flow; average = 10.)
N = Number of agents per supervisor.
R = The skill group or precision queue refresh rate configured on the CTI OS Server. (Default = 10 seconds.)
(Y * (N + 1) / R) = Number of updates per second, based on skill groups.
(Z * N * A) / 3600 = Number of updates per second, based on calls.
The CTI OS
Supervisor desktop is not impacted as long as there are fewer than 31 updates
per second. This threshold value is derived by using the above formula to
calculate the update rate for 50 agents per supervisor (N = 50), as follows:
X = (5 * (50 + 1) / 10) + ((30 * 50 * 10) / 3600) = 25.5 + 5 = 31 updates per second
The maximum number of agents per supervisor must not exceed 200 for any given configuration, still holding updates per sec to a max of 31 with above formula.
Monitor Mode Applications
A CTI OS Monitor
Mode application can impact the performance of the CTI OS Server. CTI OS
supports only two such applications per server pair. Depending on the filter
specified, the impact on the CPU utilization might degrade the performance of
the Agent PG.
monitored call adds more processing for the PG as well as Unified CM. Each
silently monitored call is equivalent to two unmonitored calls to an agent.
Make sure that the percentage of the monitored calls is within the capabilities
of PG scalability.
CTI OS Skill
Group Statistics Refresh Rate
The skill group
statistics refresh rate can also have an effect on the performance of CTI OS
Server. Cisco requires that you do not lower the refresh rate below the default
value of 10 seconds.
The call type is
also an important metric that will impact performance of most Unified CCE
server components. An increase in the number of transfers and conferences will
increase the load on the system and, thus, decrease the total capacity.
The Unified IP IVR and Unified Customer Voice Portal (CVP) place calls
in a queue and play announcements until an agent answers the call. For sizing
purposes, it is important to know whether the IVR will handle all calls
initially (call treatment) and direct the callers to agents after a short
queuing period, or whether the agents will handle calls immediately and the IVR
will queue only unanswered calls when all agents are busy. The answer to this
question determines very different IVR sizing requirements and affects the
performance of the Call Router/Logger and Voice Response Unit (VRU) PG.
translation route pool depends on the expected call arrival rate. Use the
following formula to size the translation route pool:
Translation route pool = 20 * (Calls per second)
is specific to Unified CCE. For more general Unified ICM deployments, consult
your Cisco Account Team or Partner.
complexity and/or number of Unified CCE scripts increase, the processor and
memory overhead on the Call Router and VRU PG will increase significantly. The
delay time between replaying Run VRU scripts also has an impact.
reporting can have a significant effect on Logger and Rogger
processing due to database access. A separate VM is required for an
Administration & Data Server to off-load reporting overhead from the
Logger and Rogger.
As IVR script
complexity increases with features such as database queries, the load placed on
the IVR Server and the Router also increases. There is no good rule of thumb or
benchmark to characterize the Unified IP IVR performance when used for complex
scripting, complex database queries, or transaction-based usage. Test complex
IVR configurations in a lab or pilot deployment to determine the response time
of database queries under various BHCA and how they affect the processor and
memory for the IVR server, PG, and Router.
IVR Self-Service Applications
where the Unified IP IVR is also used for self-service applications, the
self-service applications are in addition to the Unified CCE load and must be
factored into the sizing requirements as stated in sizing tables above.
Database and Cisco Resource Manager Connectivity
examine connectivity of any Unified CCE solution component to an external
device and/or software to determine the overall effect on the solution. Cisco
Unified CCE solutions are very flexible and customizable, but they can also be
complex. Contact centers are often mission-critical, revenue-generating, and
customer-facing operations. Therefore, engage a Cisco Partner (or Cisco
Advanced Services) with the appropriate experience and certifications to help
you design your Unified CCE solution.
Call Context (ECC)
The ECC usage
impacts PG, Router, Logger, and network bandwidth. There are many ways that ECC
can be configured and used. The capacity impact will vary based on ECC
configuration, handled on a case-by-case basis.
A Unified CCE
Peripheral Gateway (PG) translates messages coming from the Unified
Communications Manager servers, the Unified IP IVR, Unified CVP, or voice
response units (VRUs) into common internally formatted messages that are then
sent to and understood by Unified CCE. In the reverse, it also translates
Unified CCE messages so that they can be sent to and understood by the
The figures below
illustrate various configuration options for the Agent PG with CTI OS.
Figure 2. Agent PG
Configuration Options with CTI OS
The table below
gives sizing guidelines for PGs and PIMs.
Table 3 PG and PIM
based on Unified CCE Release 10
number of PGs per Unified CCE
number of PG types per VM
Up to two PG
types are permitted per VM, but each VM must meet the maximum agent and VRU
number of Unified Communications Manager PGs per VM
Unified Communications Manager PG, Generic PG, or System PG is allowed per VM.
number of Unified Communications Manager PIMs per PG
Can PGs be
remote from Unified CCE?
Can PGs be
remote from Unified Communications Manager?
number of IVRs controlled by one Unified Communications Manager
Can PG be
co-resident with Cisco Unified Communications Manager?
Agent Greeting Sizing Considerations
Agent Greeting invokes conference resources to bring the greeting into the call. With supported hard phones, the Built in Bridge on the phone is used. For Mobile Agent, conference resources are used. This adds a short but additional call leg to every call, which has impacts on all components.
Agent Greeting has an impact of up to 1.5 regular calls on the Router and Logger. This implies that the maximum call rate on Unified CCE is reduced from 60 calls per second to 40 calls per second, as measured by new calls that originate from the service provider. As each Agent Greeting
involves an additional route request, the Router PerfMon counter displays 80 calls per second under a full supported load. The number of agents supported per System is dependent upon the overall call rate. For a specific scenario, see the Unified CCE Sizing Tool.
Agent Greeting does have an impact on the PG resource utilization, but it is not enough impact to require reducing the supported agent capacity per PG. Other factors like additional skill groups per agent or total configured skill groups also play a factor in PG sizing. When sizing the PG, the sizing calculator factors in Agent Greeting.
When Agent Greeting and/or Mobile Agent and IP-IVR are in use, the number of agents supported by a Unified Communications Manager subscriber is impacted.
Agent Greeting with Mobile Agent uses additional Conference Bridge and MTP resources. The agent greeting calls are relatively short and they need not be factored into sizing considerations. To properly size Conference Bridge and UCM resources, indicate a conference in place of an Agent Greeting for each Mobile Agent (when Agent Greeting is enabled) for each inbound call.
CVP and VXML Gateway
Agent Greeting also utilizes CVP and VXML gateway resources, so it is important to consider the call rate when sizing. The CVP SRND includes information about how to size based on call rate; however, most deployments are sized based on the number of ports. The Agent Greeting utilization has a profile of short calls but at a high call rate, so do not overlook this consideration.
Whisper Announcement Sizing Considerations
The impact of Whisper Announcement on solution component sizing is not as significant as the impact caused by Agent Greeting. To factor in Whisper Announcement, run the Cisco Unified Collaboration Sizing Tool.
To mitigate possible overload conditions on the agent peripheral, Precision Routing limits the number of calls to the peripheral when it detects an overload condition. When this occurs, the system stops routing Precision Routing calls to that peripheral for a short period of time.
System Performance Monitoring
Supporting and maintaining an enterprise solution requires many steps and procedures. Depending on the customer environment, the support procedures vary. System performance monitoring is one procedure that helps maintain the system. This section provides a guide for monitoring Unified CCE to
ensure that the system is performing within system tolerances. System monitoring is especially critical for customers as they expand or upgrade their system. Monitor the system during times of heavy activity. For more information about monitoring, see the Serviceability Best Practices Guide for Cisco Unified ICM/Unified CCE & Unified CCH.
The following system components are critical to monitor:
The following list highlights some of the important counters for the critical system components, along with their threshold values:
Monitoring the CPU
%Processor Time; the threshold of this counter is 60%.
ProcessorQueueLength; this value must not go above (2 * [the total number of CPUs on the system]).
% Committed Bytes; this value must remain less than (0.8 * [the total amount of physical memory]).
Memory\Available MByte; this value must not be less than 16 MB.
Page File %usage; the threshold for this counter is 80%.
Monitoring the Disk Resources
AverageDiskQueueLength; this value must remain less than (1.5 * [the total number of disks in the array]).
%Disktime; this value must remain less than 60%.
Monitoring Network Resources
NIC\bytes total/sec; this value must remain less than (0.3 * [the bandwidth of the NIC]).
NIC\Output Queue Length; the threshold for this counter is 1.
Monitoring Unified CCE application
Cisco Call Router(_Total)\Agents Logged On
Cisco Call Router(_Total)\Calls in Progress
Cisco Call Router(_Total)\calls /sec
The above performance counters for CPU, memory, disk, and network are applicable to all VMs within the deployment. The preferred sample rate is 15 seconds.
Proper sizing of Unified CCE components requires analysis beyond the number of agents and busy hour call attempts. Configurations with multiple skill groups per agent, significant call queuing, and other factors contribute to the total capacity of any individual component. Careful planning
and discovery in the pre-sales process uncovers critical sizing variables; apply these considerations to the final design and hardware selection.
Correct sizing and design can ensure stable deployments for large systems up to 8000 agents and 216,000 BHCA. For smaller deployments, cost savings can be achieved with careful planning and co-resident Unified CCE components (for example, Rogger and Agent PG).
Pay careful attention to the sizing variables that impact sizing capacities such as skill groups per agent. While it is often difficult to determine these variables in the pre-sales phase, it is critical to consider them during the initial design, especially when deploying