Cisco Cisco Customer Response Solution Downloads Guía De Diseño
2-14
Cisco Unified Contact Center Express Solution Reference Network Design, Release 4.1
Chapter 2 Cisco Unified Contact Center Express Solution Architecture
Unified CCX Fault Tolerance
For more information about the IPCC Express Gateway, see the Cisco IPCC Gateway Deployment Guide
ICM/IPCC Enterprise Edition Release 7.0(0), Cisco Unified Contact Center Express, Release 5.0(1)
ICM/IPCC Enterprise Edition Release 7.0(0), Cisco Unified Contact Center Express, Release 5.0(1)
Unified CCX Fault Tolerance
The Unified CCX solution offers a number of different capabilities to provide fault tolerance. To begin
with, an Unified CCX deployment utilizes a Cisco Unified Communications network composed of Cisco
data switches and routers which provide for a highly available data network with many options for
redundancy. Cisco campus and network design guides discuss best practices for designing highly
available networks with Cisco switches and routers.
with, an Unified CCX deployment utilizes a Cisco Unified Communications network composed of Cisco
data switches and routers which provide for a highly available data network with many options for
redundancy. Cisco campus and network design guides discuss best practices for designing highly
available networks with Cisco switches and routers.
A Cisco Unified CallManager deployment utilizes a cluster approach with up to 8 call processing servers
per Cisco Unified CallManager cluster. Unified CallManager groups devices (voice gateways, IP
Phones, and CTI Ports) into device pools and allows for device pools to have a primary, secondary, and
tertiary Cisco Unified CallManager server. When a device pool’s primary Cisco Unified CallManager
server fails, the devices within that device pool automatically fail over to the secondary or tertiary Cisco
Unified CallManager server. Unified CCX CTI Ports are grouped together into CTI Call Control Groups
(often called a CTI Port Group). Each CTI Port Group is configured as part of a device pool. Cisco
Unified CallManager also supports Voice Gateways deployed at many locations with trunks from
different service providers.
per Cisco Unified CallManager cluster. Unified CallManager groups devices (voice gateways, IP
Phones, and CTI Ports) into device pools and allows for device pools to have a primary, secondary, and
tertiary Cisco Unified CallManager server. When a device pool’s primary Cisco Unified CallManager
server fails, the devices within that device pool automatically fail over to the secondary or tertiary Cisco
Unified CallManager server. Unified CCX CTI Ports are grouped together into CTI Call Control Groups
(often called a CTI Port Group). Each CTI Port Group is configured as part of a device pool. Cisco
Unified CallManager also supports Voice Gateways deployed at many locations with trunks from
different service providers.
Cisco Unified CallManager has a subsystem called the CTI Manager that abstracts the device
management from the JTAPI communications to an application server (like Unified CCX). This allows
an application to not be concerned with what specific server a device (voice gateway, agent phone, or
CTI port) is currently registered. Unified CCX has the ability to communicate with up to two CTI
Managers within a Cisco Unified CallManager cluster, but only actively communicates with one at a
time. If the active CTI Manager subsystem or the Cisco Unified CallManager node running the active
CTI Manager fails, then Unified CCX closes the sockets for all CTI ports and immediately begins JTAPI
communications with the backup CTI Manager. Calls being handled by agents survive, but if their
phones are registered with the failed Cisco Unified CallManager, then they will not be able to perform
any subsequent call control. Upon completion of existing calls, agent phones will automatically
re-register to the secondary Cisco Unified CallManager server. For agents who were not off hook, their
phones will re-register to the secondary Cisco Unified CallManager immediately.
management from the JTAPI communications to an application server (like Unified CCX). This allows
an application to not be concerned with what specific server a device (voice gateway, agent phone, or
CTI port) is currently registered. Unified CCX has the ability to communicate with up to two CTI
Managers within a Cisco Unified CallManager cluster, but only actively communicates with one at a
time. If the active CTI Manager subsystem or the Cisco Unified CallManager node running the active
CTI Manager fails, then Unified CCX closes the sockets for all CTI ports and immediately begins JTAPI
communications with the backup CTI Manager. Calls being handled by agents survive, but if their
phones are registered with the failed Cisco Unified CallManager, then they will not be able to perform
any subsequent call control. Upon completion of existing calls, agent phones will automatically
re-register to the secondary Cisco Unified CallManager server. For agents who were not off hook, their
phones will re-register to the secondary Cisco Unified CallManager immediately.
In addition to being able to fail over to another Cisco Unified CallManager node within the cluster,
Unified CCX itself provides a clustering mechanism. However, Unified CCX clustering is a little bit
different than CallManager clustering. In Cisco Unified CallManager clustering, each of the 8 servers in
the cluster has an identical database. In Unified CCX clustering, you can have up to 10 servers in an
Unified CCX cluster, but only 2 will be servers with Database components. With Unified CCX
clustering, configuration changes are made to both databases (assuming both are operational).
Unified CCX itself provides a clustering mechanism. However, Unified CCX clustering is a little bit
different than CallManager clustering. In Cisco Unified CallManager clustering, each of the 8 servers in
the cluster has an identical database. In Unified CCX clustering, you can have up to 10 servers in an
Unified CCX cluster, but only 2 will be servers with Database components. With Unified CCX
clustering, configuration changes are made to both databases (assuming both are operational).
The four different components (CRS Engine, Database, Monitoring, and Recording) all provide some
level of redundancy and fault tolerance, but each functions a little bit differently.
level of redundancy and fault tolerance, but each functions a little bit differently.
CRS Engine Redundancy
When deploying with High Availability, two CRS Engine components must be deployed on separate
servers. If one server initiates the engine mastership election first, it becomes master. The other server
becomes standby. If both servers are started approximately at the same time, it is not specified which
server becomes master. When the CRS Engine component server fails over, the standby server becomes
the master server and remains as the master server until another failure occurs. Any active calls being
processed by applications on CTI Ports will be released upon failure of the master CRS Engine server.
servers. If one server initiates the engine mastership election first, it becomes master. The other server
becomes standby. If both servers are started approximately at the same time, it is not specified which
server becomes master. When the CRS Engine component server fails over, the standby server becomes
the master server and remains as the master server until another failure occurs. Any active calls being
processed by applications on CTI Ports will be released upon failure of the master CRS Engine server.