Cisco Cisco IPCC Web Option Merkblatt
4-41
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 4 Unified Contact Center Enterprise Desktop
Deployment Considerations
Failover Redundancy and Load Balancing
Load balancing support is defined as the act of multiple RSM servers being associated together so that
the incoming request load is distributed among them. The definition of failover is multiple RSM servers
being associated together so that if one fails, the other(s) can act in its place. In the future, RSM will
support load balancing and failover with both the Unified CVP and IP IVR VRUs. Currently, this support
is not available in RSM 1.0. RSM 1.0 does, however, support the deployment of multiple standalone
RSM servers within a single Unified CCE environment, and this concept is demonstrated in the
advanced deployment scenarios described in this document.
the incoming request load is distributed among them. The definition of failover is multiple RSM servers
being associated together so that if one fails, the other(s) can act in its place. In the future, RSM will
support load balancing and failover with both the Unified CVP and IP IVR VRUs. Currently, this support
is not available in RSM 1.0. RSM 1.0 does, however, support the deployment of multiple standalone
RSM servers within a single Unified CCE environment, and this concept is demonstrated in the
advanced deployment scenarios described in this document.
indicates how a failure of each of the various components affects a live supervisor call.
Table 4-5
Impact of Failures on a Supervisor Call
Component That Fails Worst Possible Impact
VRU Node (IP IVR,
Unified CVP)
VRU Node (IP IVR,
Unified CVP)
Supervisor's call is terminated as any VRU failover occurs (depends).
Supervisor may dial back in and log in again once VRU failover is complete
and/or the original failed VRU is working again.
Supervisor may dial back in and log in again once VRU failover is complete
and/or the original failed VRU is working again.
RSM Server (Hardware
Failure)
Failure)
Callers listening to a voice stream from the failed server will have the voice
stream terminated and be returned to the main menu. Their next attempt to
make a service request to the failed server (or a new callers first attempt to
make such a request) will result in a configurable delay of 3 to 5 seconds or
so, as the request times out and an error message is played. Furthermore, any
action that attempts to contact the RSM server (for example, logging in,
attempting to monitor an agent, and so forth), will fail, although the RSM
callflow will still be answered because it is being hosted on the VRU node.
stream terminated and be returned to the main menu. Their next attempt to
make a service request to the failed server (or a new callers first attempt to
make such a request) will result in a configurable delay of 3 to 5 seconds or
so, as the request times out and an error message is played. Furthermore, any
action that attempts to contact the RSM server (for example, logging in,
attempting to monitor an agent, and so forth), will fail, although the RSM
callflow will still be answered because it is being hosted on the VRU node.
VLEngine or PhoneSIM
software failure
software failure
Service automatically restarted via service wrapper. Supervisors with a
request in-progress are given an error message and have a chance to retry
their last action. During the time either service is not functioning, any action
that attempts to contact the RSM server (for example, logging in, attempting
to monitor an agent, and so forth), will fail, although the RSM callflow will
still be answered because it is being hosted on the VRU node.
request in-progress are given an error message and have a chance to retry
their last action. During the time either service is not functioning, any action
that attempts to contact the RSM server (for example, logging in, attempting
to monitor an agent, and so forth), will fail, although the RSM callflow will
still be answered because it is being hosted on the VRU node.