Cisco Cisco E-Mail Manager Unity Integration Option プリント
3-46
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 3 Design Considerations for High Availability
Understanding Failure Recovery
Unified CM PG and CTI Manager Service
When the active CTI Manager Service or PG software fails, the PG JTAPI Gateway/PIM detects an
OUT_OF_SERVICE event and induces a failover to the redundant (duplex) PG. Because the redundant
PG is logged into the backup Unified CM subscriber CTI Manager Service already, it registers the IP
phones and configured dialed numbers or CTI route points automatically. This initialization service
takes place at a rate of about 5 devices per second. The agent desktops show them as being logged out
or not ready, and a message displays stating that their routing client or peripheral (Unified CM) has gone
off-line. (This warning can be turned on or off, depending on the administrator's preference.) All agents
and supervisors lose their desktop third-party call control functionality until the failure recovery is
complete. The agents and supervisors can recognize this event because call control action buttons on the
desktop will gray out, and they will not be able to do anything with the desktop. Any existing calls should
remain active without any impact to the caller.
OUT_OF_SERVICE event and induces a failover to the redundant (duplex) PG. Because the redundant
PG is logged into the backup Unified CM subscriber CTI Manager Service already, it registers the IP
phones and configured dialed numbers or CTI route points automatically. This initialization service
takes place at a rate of about 5 devices per second. The agent desktops show them as being logged out
or not ready, and a message displays stating that their routing client or peripheral (Unified CM) has gone
off-line. (This warning can be turned on or off, depending on the administrator's preference.) All agents
and supervisors lose their desktop third-party call control functionality until the failure recovery is
complete. The agents and supervisors can recognize this event because call control action buttons on the
desktop will gray out, and they will not be able to do anything with the desktop. Any existing calls should
remain active without any impact to the caller.
In the event that calls arrive at the CTI Route Points in Unified CM during a PG failover and the PIM is
not yet fully operational, these calls will fail unless these route points are configured with a recovery
number in their "Call Forward on Unregistered" or "Call Forward on Failure" setting. These recovery
numbers could be the Cisco Unity voicemail system for the Auto Attendant, or perhaps the company
operator position, to ensure the incoming calls are getting answered.
not yet fully operational, these calls will fail unless these route points are configured with a recovery
number in their "Call Forward on Unregistered" or "Call Forward on Failure" setting. These recovery
numbers could be the Cisco Unity voicemail system for the Auto Attendant, or perhaps the company
operator position, to ensure the incoming calls are getting answered.
Note
Agents should not push any buttons during desktop failover because these keystrokes can be buffered
and sent to the CTI server when it completes its failover and restores the agent states.
and sent to the CTI server when it completes its failover and restores the agent states.
When an active PG fails over to the idle side, calls still in progress will be recovered by querying
Unified CM as part of the activation sequence. There will be two Termination Call Detail records
providing information on the call prior to and after the PG transition. Peripheral call variables and ECC
variables will be lost on the agent desktop. Indication of whether the call was a barge-in or a conference
call will be lost on the agent desktop and in reports. Calls that were in the wrap-up state will not be
recovered. Agents will be able to release, transfer, or conference calls from their agent desktop after
activation completes.
Unified CM as part of the activation sequence. There will be two Termination Call Detail records
providing information on the call prior to and after the PG transition. Peripheral call variables and ECC
variables will be lost on the agent desktop. Indication of whether the call was a barge-in or a conference
call will be lost on the agent desktop and in reports. Calls that were in the wrap-up state will not be
recovered. Agents will be able to release, transfer, or conference calls from their agent desktop after
activation completes.
Note
Call and agent state information might not be complete at the end of a failover if there are call status and
agent state changes during the failover window.
agent state changes during the failover window.
Unified ICM Voice Response Unit PG
When a Voice Response Unit (VRU) PG fails, all the calls currently in queue or treatment on that Unified
IP IVR are dropped unless there is a default script application defined or the CTI Ports have a recovery
number defined in Unified CM for their "Call Forward on Failure" setting. Calls in progress or queued
in Unified CVP are not dropped and will be redirected to a secondary Unified CVP or number in the
H.323 or SIP dial plan, if available by the Survivability TCL script in the voice gateway.
IP IVR are dropped unless there is a default script application defined or the CTI Ports have a recovery
number defined in Unified CM for their "Call Forward on Failure" setting. Calls in progress or queued
in Unified CVP are not dropped and will be redirected to a secondary Unified CVP or number in the
H.323 or SIP dial plan, if available by the Survivability TCL script in the voice gateway.
The redundant (duplex) VRU PG side will connect to the Unified IP IVR or CVP and begin processing
new calls upon failover. Upon recovery of the failed VRU PG side, the currently running VRU PG
continues to operate as the active VRU PG. Therefore, having redundant VRU PGs adds significant value
because it allows an IP IVR or CVP to continue to function as an active queue point or to provide call
treatment. Without VRU PG redundancy, a VRU PG failure would block use of that IP IVR even though
the IP IVR is working properly. (See
new calls upon failover. Upon recovery of the failed VRU PG side, the currently running VRU PG
continues to operate as the active VRU PG. Therefore, having redundant VRU PGs adds significant value
because it allows an IP IVR or CVP to continue to function as an active queue point or to provide call
treatment. Without VRU PG redundancy, a VRU PG failure would block use of that IP IVR even though
the IP IVR is working properly. (See