Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
Sizing Unified CCE Components and Servers
Downloads: This chapterpdf (PDF - 1.9MB) The complete bookPDF (PDF - 12.19MB) | The complete bookePub (ePub - 7.08MB) | Feedback

Sizing Unified CCE Components and Servers

Contents

Sizing Unified CCE Components and Servers

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 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 best design practices focusing on scalability and capacity for Unified CCE deployments. The design considerations, best practices, 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.

Sizing Tools

Sizing tools are available online.

The sizing tools are available to Cisco internal employees and Cisco partners only, and proper login authentication is required.

Sizing Considerations for Unified CCE

This section discusses Unified CCE sizing considerations.

Core Unified CCE Components

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 (Unified CM) capacity and sizing of Cisco Unified Communications components, see Sizing Cisco Unified Communications Manager Servers and the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​tsd_​products_​support_​series_​home.html.

Additionally, because of varying agent and skill group capacities, consider proper sizing of the Agent PG, including CTI OS and Cisco Agent Desktop servers, together with the Cisco Unified Communications components.

Finally, the 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.


Note


Unless otherwise explicitly noted, the capacity information presented in Operating 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.



Note


Sizing considerations are based on capacity and scalability test data. Major Unified CCE software processes were run on individual servers 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 CPU servers. This information is meant as a guide for determining when Unified CCE software processes can be co-resident within a single Server and when certain processes need their own dedicated server. Table 1 assumes that the deployment scenario includes two fully redundant servers that are deployed as a duplexed pair.



Note


The Cisco Unified Contact Center solution does not provide a quad-processor Cisco MCS Unified CM appliance at this time. For the most current server specifications, see the latest version of the Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/​Contact Center Enterprise & Hosted.


Operating Conditions

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 IVR call.
  • Five Expanded Call Context (ECC) scalars.
  • Transport Layer Security (TLS) for CTI OS is turned OFF.
  • No mobile agents.
  • One all-events CTI server client.
  • 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
  • Server types:
    • APG = Agent Peripheral Gateway
    • PGR = Progger
    • RGR = Rogger
Figure 1. Minimum Servers Required for Release 8.0(x) 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 CM components are not shown.
  • For more information, see Peripheral Gateway and Server Options.

Note


The terms Rogger and Central Controller are used interchangeably throughout this chapter.


Figure 2. Minimum Servers Required for Release 8.0(x) and Later Unified CCE Deployments with Cisco Agent Desktop

The following notes apply to the figure above:
  • Sizing is based on the information listed under Operating Conditions.
  • Voice Response Unit (VRU), Administration & Data Server, and Unified CM components are not shown.
  • For more information, see Peripheral Gateway and Server Options.
  • The maximum values apply to all CAD clients (CAD, IPPA, and CAD-BE).
Table 1 Sizing Information for Unified CCE Components and Servers
Component Server Class Maximum Agents (local agents without agent greeting) Notes
Progger: Peripheral Gateway, Router, and Logger    

Cannot be co-resident with an Administration & Data Server. In addition, the Progger cannot have additional Agent Peripheral Gateways.

Logger database is limited to 14 days of historical data.

MCS-30-004-Class

CTI OS: 100 CAD: No

With MCS-30-004-Class servers:

  • Maximum number of simultaneous queued calls equals half the number of agents.
  • Outbound:

    (Maximum PG agent capacity) – (4 x [number of SCCP dialer ports])

    or

    (Maximum PG agent capacity) – (1.33 x [number of SIP Dialer ports])

  • To determine the maximum Progger agent capacity, see the Progger inbound Agent entry in this table. The capacity depends on your ICM software release.

MCS-40-005-Class

CTI OS: 450 CAD: 297

With MCS-40-005-Class servers:

  • Maximum number of simultaneous queued calls equals half the number of agents.
  • Outbound:

    (Maximum PG agent capacity) – (4 x [number of SCCP dialer ports])

    or

    (Maximum PG agent capacity) – (1.33 x [number of SIP Dialer ports])

  • To determine the maximum Progger agent capacity, see the Progger inbound Agent entry in this table. The capacity depends on your ICM software release.
Router

MCS-30-004-Class

500  
Router and Logger

MCS-40-005-Class

4000  
Logger

MCS-40-006-Class

6000 MCS-30-00x-Class servers are not supported.
Logger

GEN-50-006-Class

GEN-50-007-Class

12,000 After you install the Unified Contact Center Enterprise Logger component in a large capacity deployment (>8,000 agents), you must adjust the Microsoft SQL server Jobs for daily purge. Use Microsoft SQL Management Studio; adjust the following purge jobs to be 30 minutes apart from one another during a non-busy call volume interval: TCD, RCD, RCV, and TCV. It is important to monitor the SQL server purge jobs to be sure that they are completing successfully and the four purge jobs mentioned before are not overlapping. If they are overlapping, and causing performance related issues on the logger, further adjustments of the jobs may be required.
Router

MCS-40-005-Class

8000 MCS-30-00x-Class servers are not supported.
Router

MCS-40-015-Class

MCS-40-016-Class

12,000  
Logger

GEN-50-005-Class

8000 MCS-30-00x-Class servers are not supported.
Administration & Data Server     For the most current hardware specifications for Administration & Data Server, see the latest version of the Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/​Contact Center Enterprise & Hosted, Release 9.0(x).
Agent PG (Inbound Only)  

MCS-30-004-Class

CTI OS: 450 CAD: 297

For more information about the various Agent PG deployment options, see the section Peripheral Gateway and Server Options.

VRU Ports: Additional VRU PGs can be deployed to accommodate a greater number of VRU ports.

Mobile Agents: Use the following calculations to determine mobile agent capacity:

  • Each mobile agent for a nailed connection (nailed-up configuration): Equals 1.73 local agents for Release 8.0(x)
  • Each mobile agent for a call-by-call basis: Equals 2.4 local agents for Release 8.0(x)
Support for 4000 agents is limited to multiple Unified CM PIMs and multiple CTI OSs:
  • 2 to 10 Unified CM PIMs
  • 2 to 10 CTI OSs (Number of CTI OSs has to be equal to number of Unified CM PIMs)
  • No VRU PIMs
    Note   

    The Cisco Media Blender is not supported when installed on a PG system.

 

MCS-40-005-Class

CTI OS: 2000, 4000 CAD: 1000  
Voice Response Unit (VRU) PG     Use the number of ports instead of agent count. Average of 5 Run VRU Script Nodes per call.

MCS-30-004-Class

1200 ports Maximum of 4 PIMs; maximum of 10 cps.

MCS-40-005-Class

9600 ports Maximum of 10 PIMs; maximum of 40 cps.
Agent PG with Outbound Voice (Includes Dialer and Media Routing PG)   [Maximum inbound agent capacity] - 4 * [Number of SCCP Dialer ports] Or [Maximum inbound agent capacity] – 1.33 * [Number of  SIP Dialer ports]  

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.

The formula is an indicator of platform capacity. This is not an indicator of 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 CAD and 10 SCCP Dialer ports.

Available inbound CAD agents = 1000 - (4*10) = 960.

Note   

The Cisco Media Blender is not supported when installed on a PG system.

Silent Monitor Server

MCS-30-004-Class

20 (Simultaneous recording sessions)  

MCS-40-005-Class

40 (Simultaneous recording sessions)  
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 documentation.
Cisco Unified Customer Voice Portal (CVP) Application Server And Voice Browser     For the most current server specifications for Unified CVP, see the latest version of the Hardware and System Software Specification for Cisco Unified CVP.
Unified IP IVR Server     For the most current Unified IP IVR server specifications, see the documentation available through valid Cisco Employee or Partner login.
Cisco Unified Intelligence Center (Unified Intelligence Center)     For the most current server specifications for Unified Intelligence Center, see the latest version of the Cisco Unified Intelligence Center Bill of Materials.

In addition to the MCS models listed above, there are other server models based on Intel Xeon Nehalem quad-core technology that can be used for Unified CCE deployments. For further details, see the latest version of the Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/​Contact Center Enterprise & Hosted, Release 9.0(x).

Additional Sizing Factors

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. In addition, Table 1 summarizes the sizing variables and their effects.

Busy Hour Call Attempts (BHCA)

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 Communications Manager 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 basis.

Agents

The number of agents is another important metric that will impact the performance of most Unified CCE server components, including Unified Communications Mananger clusters. For the impact of agents on the performance of Unified Communications Mananger components, see Sizing Cisco Unified Communications Manager Servers.

Average Skill 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.

Queue (skill 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 numbers in this table are based on the information listed in the section on Operating Conditions, and it shows capacity per 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 supported.


Note


Each Precision 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. For information about 12,000 agent support, see the Hardware and System Software Specification (Bill of Materials) for Cisco Unified ICM / Contact Center Enterprise & Hosted.

Table 2 Sizing Effects Due to Number of Skill Groups/Precision Queues per Agent (12,000 Agents)
Avg Configured PQ or SG per Agent System Generic PG Limits
Max Concurrent Agent per System Max Concurrent Agent per PG Max Configured SG per PG Max Configured VRU Ports per PG Max Configured VRU PIMs per PG
5 12000 2000 3000 1000 5
10 11038 1832 3000 1000 5
15 10078 1663 3000 1000 5
20 9116 1495 3000 1000 5
25 8156 1326 3000 1000 5
30 7194 1158 3000 1000 5
35 6234 989 3000 1000 5
40 5272 820 3000 1000 5
45 4312 652 3000 1000 5
50 3350 484 3000 1000 5
Table 3 Sizing Effects Due to Number of Skill Groups/Precision Queues per Agent (8000 Agents)
Avg Configured PQ or SG per Agent System Generic PG Limits
Max Concurrent Agent per System Max Concurrent Agent per PG Max Configured SG per PG Max Configured VRU Ports per PG Max Configured VRU PIMs per PG
5 8000 2000 3000 1000 5
10 7342 1832 3000 1000 5
15 6683 1663 3000 1000 5
20 6024 1495 3000 1000 5
25 5364 1326 3000 1000 5
30 4705 1158 3000 1000 5
35 4047 989 3000 1000 5
40 3389 820 3000 1000 5
45 2730 652 3000 1000 5
50 2072 484 3000 1000 5

Note


CTI OS monitor mode applications are supported only at 20 or lower skill groups per agent.


Supervisors and Teams

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.


Note


Supervisors can monitor only agents within their own team, all of whom must be configured on the same peripheral.



Note


You can add a maximum of 50 agents per team.



Note


You can add a maximum of 10 supervisors per team.


A Unified CCE 9.x system can 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

Where:

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.

CTI OS 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.

Unified Communications Manager Silent Monitor

Each silently monitored call adds more processing for the PG as well as Unified Communications Manager. 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.

Call Types

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.

Queuing

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.
Sizing the 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)

This calculation is specific to Unified CCE. For more general Unified ICM deployments, consult your Cisco Account Team or Partner.

Unified CCE Script Complexity

As the 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

Real-time reporting can have a significant effect on Logger, Progger, and Rogger processing due to database access. A separate server is required for an Administration & Data Server to off-load reporting overhead from the Logger, Progger, and Rogger.

IVR Script Complexity

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.

Unified IP IVR Self-Service Applications

In deployments 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 Table 1.

Third-Party Database and Cisco Resource Manager Connectivity

Carefully 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.

Expanded 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.

Peripheral Gateway and Server Options

A Unified CCE Peripheral Gateway (PG) translates messages coming from the Unified CM 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 peripheral devices.

The figures below illustrate various configuration options for the Agent PG with CTI OS and Cisco Agent Desktop. Table 1 lists PG and PIM sizing guidelines.

Figure 3. Agent PG Configuration Options with CTI OS

Figure 4. Agent PG Configuration Options with Cisco Agent Desktop

Table 4 PG and PIM Sizing Guidelines

Sizing Variable

Guidelines Based on Unified CCE Software Releases 8.0(x)

Maximum number of PGs per Unified CCE

250

Maximum number of PG types per server platform

Up to two PG types are permitted per server, provided that any given server is limited to the maximum agent and VRU port limitations outlined in Table 1.

Maximum number of Unified CM PGs per server

Only one Unified CM PG, Generic PG, or System PG is allowed per physical server.

Maximum number of Unified CM PIMs per PG

10 Unified CM PIMs with associated Agents can be configured per PG, provided that any given server is limited to the maximum agent and VRU port limitations outlined in Table 1.

However, if any VRU PIM is configured, a generic PG cannot support configuration of more than 1 CM PIM.

See Peripheral Gateway Design Considerations for more information.

Can PGs be remote from Unified CCE?

Yes

Can PGs be remote from Unified CM?

No

Maximum number of IVRs controlled by one Unified CM

See the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​tsd_​products_​support_​series_​home.html.

Maximum number of CTI servers per PG

1

Can PG be co-resident with Cisco MCS Unified CM appliance?

No

Cisco Agent Desktop Component Sizing

Server capacities for the Cisco Agent Desktop CTI Option vary based on the total number of agents, whether or not Switched Port Analyzer (SPAN) Monitoring and Recording is used, and the number of simultaneous recordings.

This section presents sizing guidelines for the Cisco Agent Desktop Server components.

CTI OS for Cisco VXI

When you deploy VDI or VXI, the performance, bandwidth, and timing requirements for CTI-OS (as defined in this document) must still be met. Agents will observe delays or other negative side effects if the VDI or VXI is deployed in a way that doesn't give enough performance or bandwidth to the VDI clients.

The number of VDI clients that can run within the Citrix or VMWare server is dependent on a number of factors including the footprint of other applications that are run in the deployment. Verify proper sizing to ensure that CTI-OS desktops function properly (for more information, see the Compatibility Matrix).

Cisco Agent Desktop Base Services

The Cisco Agent Desktop Base Services consist of a set of application servers that run as Microsoft Windows services. They include Chat Service, Directory Services, Enterprise Service, Unified IP Phone Agent Service, LDAP Monitor Service, Licensing and Resource Manager Service, Recording and Statistics Service, and Sync Service. In addition, there are application servers that may be placed on the same or separate computers as the Base Servers. These additional applications include the VoIP Monitor Service and the Recording and Playback Service.

A set of Cisco Agent Desktop Base Services plus the additional application servers, single or redundant installation, correspond to a logical call center (LCC) and are associated with a PG pair.

Cisco Agent Desktop VoIP Monitor Service

The VoIP Monitor Service enables the Silent Monitoring and Recording features. For Desktop Monitoring, the VoIP Monitor Service has no impact on design guidance for Agent PG scalability. When using Switched Port Analyzer (SPAN) monitoring, the VoIP Monitor Service may be co-resident on the Agent PG for up to 100 agent phones. When SPAN Monitoring and Recording are required for more than 100 phones, the VoIP Monitor Service must be deployed on a dedicated server (an MCS-30-003-Class server or equivalent). Each dedicated VoIP Monitor Service can support up to 400 phones if a 100 Megabit NIC is used to connect to the switch or 1000 phones if a Gigabit NIC is used.

Cisco Agent Desktop Recording and Playback Service

The Recording and Playback Service stores the recorded conversations and makes them available to the Supervisor Log Viewer application.

A co-resident Recording and Playback Service can support up to 32 simultaneous recordings. A dedicated Recording and Playback Service (which is available in the Premium offering) can support up to 80 simultaneous recordings. The capacity of the Recording and Playback Service is not dependent on the codec that is used.

The following table summarizes the raw Recording and Playback Service capacity.

Table 5 Capacity of Recording and Playback Service

Recording and Playback Service Type

Maximum Simultaneous Recordings

Co-resident

32

Dedicated

80

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.

Central Controller

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.

Peripheral Gateway

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, as does having two agent peripherals on the same PG. When sizing the PG, the sizing calculator factors in Agent Greeting.

Communications Manager

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.

The Cisco Unified Collaboration Sizing Tool takes call rate and the other factors into account to determine the capacity for a specific scenario.

Mobile Agent

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.

Congestion Control

Unified CCE 9.0 introduced the Congestion Control Feature, which provides protection to the Central Control Router from overload conditions, due to high call rates. The main objective of congestion control is to keep the system running close to its rated capacity, when faced with extreme overload. The goal is to give satisfactory service to a smaller percentage of calls (your capacity) rather than a highly degraded service to all the calls, during an overloaded condition. This is achieved by restricting capacity on the system by rejection calls by the Routing Clients at the call entry point. Throttling the capacities ensures the service of those calls routed is successful, meaning no lates or timeouts.

The measured CPS at router is the trigger for identifying congestion in the system. For a given deployment, the supported capacity is set when the deployment type is selected. The router measures the new incoming call requests from all the routing clients and computes moving weighted average over sample duration. If the average CPS exceeds beyond the thresholds for each level, the congestion levels are changed along with the reduction percentage. The congestion control algorithm utilizes 3 congestion levels and rejects/treats the incoming calls as per the reduction percentage for that level. The change in congestion level is notified to the routing clients: NICs and PGs. The routing clients start rejecting/treating calls based on reduction percentage.

For every instance of ICM/CCE deployment, the user needs to select the type of deployment. As part of the deployment type selection, the CPS capacity is automatically set. In a multiple instance deployments like Network Application Manager/Customer ICM (NAM/CICM) as shown in the following diagram, the congestion control is done based on the call rate measured at each instance. The calls rejected are treated based on the congestion level in that instance. For example, if a call arrives at NAM instance through VRU PGs or NICs, if NAM router is congested, then the VRU PGs or NICs will apply the congestion logic and reject/treat the calls. Similarly if the CICM is congested, and NAM does CICM lookup for routing any calls, such calls are subjected to congestion control at INCRP NIC at CICM instance.

Figure 5. NAM/CICM Deployment

Deployment Types

After upgrading or installing the system, configure the system to a valid deployment type. The following table lists the supported deployment types with guidelines for selecting a valid deployment type.

Table 6 Deployment Types

Deployment Type Code

Deployment Name

Guidelines for Selection

0

Not Specified

This is a system default deployment type. User cannot select this option; is the default setting after fresh install/upgrade.

1

NAM

Select this deployment type for NAM instance in a Hosted ICM/CCEH deployment. The system should be distributed deployment with Router and Logger installed on different servers, which meets the requirements specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)).No agents are allowed in this deployment type. If agents are configured and logged in, the capacity is adjusted to maximum capacity of an Enterprise Contact Center (Unified CCE 12000 Agents Router/ Logger).

2

IVR-ICM

Select this deployment type for ICM instance which is dedicated to self service call flows using Unified CVP or third party IVR systems. The system should be distributed deployment with Router and Logger installed on different servers which meets the requirements specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)). No agents are allowed in this deployment type. If agents are configured and logged in, the capacity is adjusted to maximum capacity of an Enterprise Contact Center (Unified CCE 12000 Agents Router/ Logger).

3

NAM Rogger

Select this deployment type for NAM instance in a Hosted ICM/CCEH deployment. The Router and Logger co-located on a single server meet the requirements specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)). No agents are allowed in this deployment type. If agents are configured and logged in, the capacity is adjusted to maximum capacity of an Enterprise Contact Center (Unified CCE 12000 Agents Router/ Logger).

4

ICM Router/Logger

Select this deployment for type ICM Enterprise system where both Legacy TDM ACD PGs and CCE PGs are deployed. The system should be distributed deployment with Router and Logger installed on different servers which meet the requirements specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)).

5

Unified CCE 8000 Agents Router/ Logger

Select this deployment for type CCE Enterprise system where only CCE PGs are deployed. The system should be distributed deployment with Router and Logger installed on different servers which meet the requirements for 8000 CCE agents as specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)).

6

Unified CCE 12000 Agents Router/ Logger

Select this deployment type for CCE Enterprise system where only CCE PGs are deployed. The system should be distributed deployment with Router and Logger installed on different servers which meet the requirements for 12000 CCE agents as specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)).

7

Packaged CCE : CCE-PAC-M1

Select this deployment type when Packaged CCE: CCE-PAC-M1 is being deployed.

8

ICM Rogger

Select this deployment type for ICM Enterprise system where both Legacy TDM ACD PGs and CCE PGs are deployed. The Router and Logger are co-located on a single server which meets the requirements specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)).

9

Unified CCE 4000 Agents Rogger

Select this deployment type for CCE Enterprise system where only CCE PGs are deployed. The system should be distributed deployment with Router and Logger installed on different servers which meet the requirements for 4000 CCE agents as specified in Cisco ICM/​Contact Center Enterprise and Hosted Hardware and System Software Specification (Bill of Materials (BOM)).

10

Packaged CCE : CCE-PAC-M1 Lab Only

Select this deployment type when Packaged CCE: CCE-PAC-M1 Lab is being deployed.

11

HCS-CC 1000 Agents

Select this deployment type when HCS-CC 1000 Agents is being deployed.

12

HCS-CC 500 Agents

Select this deployment type when HCS-CC 500 Agents is being deployed.

13

Unified CCE 450 Agents Progger

Select this deployment type when Router, Logger and PG are installed on the same server. For all lab deployments, this type should be selected although Router, Logger and PG are not on the same box.

Note   

Progger deployment is not supported for production use.


Note


It is very important to assess the deployment type of the system and set it in the configuration. In case of wrong deployment type selection, the system will either be unprotected from overload or will reject/treat the calls based on incorrect capacity settings.


Congestion Treatment Mode

There are five options available to handle the calls that are to be rejected or treated due to congestion in the system. Contact center administrators can choose any of the following options to handle the calls:
  • Treat Call with Dialed Number Default Label - The calls to be rejected due to congestion are treated with the default label of the dialed number on which the new call has arrived.
  • Treat call with Routing Client Default Label - The calls to be rejected due to congestion are treated with the default label of the routing client on which the new call has arrived.
  • Treat call with System Default Label - The calls to be rejected due to congestion are treated with the system default label set in Congestion Control settings.
  • Terminate call with a Dialog Fail or RouteEnd - Terminates the new call dialog with a dialog failure.
  • Treat call with a Release Message to the routing client - Terminates the new call dialog with a release message.

The treatment options are set either at routing client or at global level system congestion settings. If the treatment mode is not selected at the routing client, the system congestion settings are applied for treating the calls.


Note


If you select the treatment option to return a label back to treat the call with an announcement, then the announcement system should be external to CCE instance. In any case the call that is treated should not be re-entered into system for further processing.


Congestion Control Levels and Thresholds

Congestion Control algorithm works in three levels and each level has onset and abatement values. Moving to a higher congestion level will happen when the average CPS exceeds the level’s onset value. For example, if the system is at level 0 and the CPS measured exceeded Level 2 onset capacity then the congestion is directly moved to Level 2. Moving back to lower congestion level will occur when the average CPS measured falls below the level’s abatement value. Congestion levels can rise from any level to any level. However the congestion level is reduced one level at a time.

Table 7 Congestion Levels

Congestion Levels

Congestion Level Threshold (Percent of Capacity)

Description

Level1Onset

110%

Level 1 Onset value: if the average CPS exceeds this value, the congestion level moves to Level 1.

Level1Abate

90%

Level 1 Abatement value: if the average CPS goes below this value, the congestion level moves back to Level 0 (Normal operating Level).

L1Reduction

10%

 The percentage of incoming calls that are rejected at Level 1 congestion.

Level2Onset

130%

Level 2 Onset value: if the average CPS reaches higher than this value, the congestion level moves to Level 2.

Level2Abate

100%

Level 2 Abatement values, if the average CPS goes below this value, then the congestion level moves back to Level 1.

Level2Redution

30%

 The percentage of incoming calls that are rejected in Level 2 congestion.

Level3Onset

150%

Level 3 Onset value: if the average CPS reaches higher than this value, the congestion level moves to Level 3.

Level3Abatement

100%

Level 3 Abatement value: if the average CPS goes below this value, the congestion level moves back to Level 2.

Level3Reduction

Variable reduction from 100% to 10%

The percentage of incoming calls that are rejected in Level 3 congestion. Depending on the incoming call rate, the reduction percentage varies from 30% to 100% when the congestion level enters Level 3.


Note


The onset, abate and reduction settings are system defined and are not configurable by the user. These values are defined as a percentage of the CPS capacity that is defined for the system.


Real-Time Capacity Monitoring

The "System Capacity Real-time" real-time report provides congestion level information to the user. This report is based on table System_Capacity_Real_Time in the Database Schema Guide for Cisco Unified Contact Center Enterprise. The report provides the following views:
  • Congestion Information View
  • Rejection Percentage View
  • Key Performance Indicators View
  • System Capacity View

For a detailed description of these reports refer to the Report Template Reference Guide for Cisco Unified Intelligence Center.

Congestion Control Configuration

Congestion control settings can be configured using the Congestion Settings Gadget and Routing Client Explorer tool. The system level congestion control can be set using the congestion control settings. And the routing client level treatment options can be selected using the Routing Client Explorer tool.

Upon selecting the deployment type, the system starts computing the various metrics related to the congestion control and system capacity, and generate the real-time report. However, the system does not reject/treat the calls until you enable the Congestion Enabled option on the Settings tab of the Unified CCE Administration tool.

Congestion Level Notification

To notify the CCE administrators, the congestion level changes are logged to Windows application events. Additionally they are sent as SNMP TRAPs and are targeted to Network Management system as configured in Unified CCE SNMP Management settings.

Special Cases of Call Treatment

The special cases of call treatment are as follows:
Outbound Option
When Media Routing Peripheral Gateway (MRPG) is integrated for outbound option, the PG’s routing client should be configured to always send the dialog failure. The rejected reservation calls are retried by the dialer after a specified interval of time.
Gate Keeper NIC
The various call treatment options are not available on Gate Keeper NICs. The congested calls can only be rejected by the routing client. The Gate Keeper NIC routing client has to be configured to the option Terminate call with a Dialog Fail or RouteEnd in routing client configuration.
Stentor NIC
The Stentor NIC does not support the congestion control. If Stentor NIC is installed and the system is congested, the call rejection is not possible for Stentor NIC. This will result in other routing client in the system rejecting more calls if the system is congested.

Special Operating Condition

This feature is supported by ICM/CCE 9.0(1) and later releases, and requires both Central Controller and PGs to effectively control the overload. The pre 9.0(1) PG routing clients are not capable of rejecting the calls. When a large deployment is undergoing an upgrade to 9.0(1) release, there is a period of time when the PGs are still operated with pre 9.0 releases. In such cases, the PGs which are in 9.0(1) starts rejecting the calls but pre 9.0 PGs will not reject the call. Hence there may be a possibility where 9.0 PGs rejecting more call until all the PGs are upgraded.

The following options should be considered while upgrading the system:
  • Upgrade all PG before enabling the congestion control - Enable congestion to reject/treat calls only after all the PGs in the system is upgraded to 9.0. This will ensure uniform rejection of calls across all the routing clients in system.
  • Upgrade selected PGs: If there are options in the enterprise where few PGs can reject more calls, upgrade those PGs first and then the remaining PG.

Peripheral Throttling

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.

The following system components are critical to monitor:
  • CPU
  • Memory
  • Disk
  • Network
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]).
  • Monitoring Memory
    • % 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 physical size 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

Note


The above performance counters for CPU, memory, disk, and network are applicable to all servers within the deployment. The preferred sample rate is 15 seconds.


Summary

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, Progger, Rogger, and Agent PG).

Additionally, pay careful attention to the sizing variables that will 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 co-resident PGs and Proggers. While new versions will scale far higher, the Cisco Agent Desktop Monitor Server is still limited in the number of simultaneous sessions that can be monitored by a single server when Monitoring and Recording are required.