Cisco Unified Contact Center Enterprise Solution Reference ...
Cisco Unified Contact Center Enterprise Solution Reference ...
Cisco Unified Contact Center Enterprise Solution Reference ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Cluster Guidelines and Considerations<br />
10-6<br />
<strong>Cisco</strong> <strong>Unified</strong> <strong>Contact</strong> <strong>Center</strong> <strong>Enterprise</strong> 7.x SRND<br />
Chapter 10 Sizing <strong>Cisco</strong> <strong>Unified</strong> CallManager 4.x and 5.x Servers<br />
Similarly, distribute all gateway ports and <strong>Unified</strong> IP IVR CTI ports equally among the cluster<br />
nodes.<br />
If you require more than one <strong>Unified</strong> ICM JTAPI user (CTI Manager) and more than one primary<br />
subscriber, then group and configure all devices monitored by the same <strong>Unified</strong> ICM JTAPI User<br />
(third-party application provider), such as <strong>Unified</strong> ICM route points and agent devices, on the same<br />
server if possible.<br />
CTI Manager should be enabled only on call processing subscribers, thus allowing for a maximum<br />
of eight CTI Managers in a cluster. To provide maximum resilience, performance, and redundancy,<br />
<strong>Cisco</strong> recommends that you load-balance CTI applications across the various CTI Managers in the<br />
cluster. While it is possible to support up to 2000 agents via a single CTI Manager (and, thus, a<br />
single IPCC Peripheral Gateway), any deployment with over 1000 agents per CTI Manager and<br />
IPCC Peripheral Gateway requires prior approval from <strong>Cisco</strong> Bid Assurance. For additional CTI<br />
Manager best practices, refer to the <strong>Cisco</strong> <strong>Unified</strong> Communications <strong>Solution</strong> <strong>Reference</strong> Network<br />
Design (SRND), available at<br />
www.cisco.com/go/srnd<br />
If you have a mixed cluster with <strong>Unified</strong> CCE and general office IP phones, group and configure<br />
each type on a separate server if possible (unless you need only one subscriber server). For example,<br />
all <strong>Unified</strong> CCE agents and their associated devices and resources (gateway ports, CTI ports, and so<br />
forth) would be on one or more <strong>Cisco</strong> <strong>Unified</strong> CallManager servers, and all general office IP phones<br />
and their associated devices (such as gateway ports) would be on other <strong>Cisco</strong> <strong>Unified</strong> CallManager<br />
servers, as long as cluster capacity allows. You have to run the <strong>Cisco</strong> <strong>Unified</strong> CallManager Capacity<br />
Tool multiple times with the specific device configuration for each primary <strong>Cisco</strong> <strong>Unified</strong><br />
CallManager server because the tool assumes all devices are equally balanced in a cluster. In this<br />
case, <strong>Cisco</strong> strongly recommends the 1:1 redundancy scheme. (See <strong>Cisco</strong> <strong>Unified</strong> CallManager<br />
Redundancy, page 10-8, for details.)<br />
<strong>Cisco</strong> recommends that you use hardware-based conference resources whenever possible. Hardware<br />
conference resources provide a more cost-effective solution and allow better scalability within a<br />
<strong>Cisco</strong> <strong>Unified</strong> CallManager cluster.<br />
All CTI route points associated with the IPCC Peripheral Gateway (PG) JTAPI user should be<br />
configured to register with the subscriber node running the CTI Manager instance that is<br />
communicating with that IPCC PG.<br />
The <strong>Cisco</strong> <strong>Unified</strong> CallManager Capacity Tool does not currently measure CTI Manager impact on<br />
each server separately. However, CTI Manager does place an additional burden on the subscriber<br />
node running that process. Therefore, for large deployments, <strong>Cisco</strong> recommends configuring<br />
slightly fewer agents and BHCA on that server (compared with the other servers in the cluster). The<br />
goal is to distribute call processing across all servers as evenly as possible.<br />
Devices that are associated with an ICM PG JTAPI user but are not used by a call center agent,<br />
should still be counted as an agent device because the PG will still be notified of all device state<br />
changes for that phone even though it is not being used by an agent. If a device is unlikely to be used<br />
regularly by a call center agent, <strong>Cisco</strong> recommends that you do not associate the device with the<br />
ICM PG JTAPI user in order to increase cluster scalability.<br />
For deployments requiring large numbers of IVR ports, <strong>Cisco</strong> recommends using CVP instead of<br />
IP IVR. IP IVR ports place significant call processing burden on <strong>Cisco</strong> <strong>Unified</strong> CallManager, while<br />
CVP does not. Thus, <strong>Unified</strong> CCE deployments with CVP will allow more agents and higher BHCA<br />
rates per cluster. All deployments should be sized using the <strong>Cisco</strong> <strong>Unified</strong> CallManager Capacity<br />
Tool.<br />
Note System IPCC does not support CVP at this time.<br />
OL-8669-05