The prerequisites for CTI failover are as
follows:
Unified Contact Center Enterprise (Unified CCE) is configured in a duplex
mode.
The B Side CTI host and port are configured through
the Finesse Administration Console (see
Server Settings).
If Finesse loses connection to the
A Side CTI server, and the preceding prerequisites have been implemented, CTI
failover occurs.
When Finesse is used in a duplex Unified CCE
deployment, and it loses connection to the A Side CTI server, it tries to
reconnect five times. If the number of connection attempts exceeds the retry
threshold, Finesse then tries to connect to the B Side CTI server the same
number of times. Finesse keeps repeating this process until it makes a
successful connection to the CTI server.
A loss of
connection to the CTI server can occur due to the following:
Finesse misses three consecutive heartbeats from the connected CTI
server.
Finesse encounters a failure on the socket
opened to the CTI server.
During failover, Finesse does
not handle client requests. Any request made during this time receives a 503
"Service Unavailable" error message. In addition, Finesse does not send out
events during this period. After Finesse reconnects to a CTI server, it starts
responding to client requests and publishing events.
Any call
control, call data, or agent state actions that occur during CTI failover are
published as events to the Agent Desktop after failover is complete. This
allows Finesse clients to reflect an accurate view of the call control, call
data, and agent state.
If an agent makes or answers a call and
ends that call during failover (that is, the entire call takes place during failover), the corresponding events are not published
after failover is complete.
Note
An agent or supervisor who signs in after
being on an active conference with other devices (which are not associated with
another agent or supervisor) may experience unpredictable behavior with the
Finesse Desktop due to incorrect call notifications from Unified CCE. These
limitations also encompass failover scenarios where a failover occurs while the
agent or supervisor is participating in a conference call. For example, an
agent is in a conference call when the Finesse server fails. When the agent is
redirected to the other Finesse server, that agent may see unpredictable
behavior on the Finesse Desktop. Examples of unpredictable behavior include,
but are not limited to, the following:
The desktop does not reflect all participants in a conference
call.
The desktop does not reflect that the signed-in
agent or supervisor is in an active call.
Finesse receives
inconsistent call notifications from Unified CCE.
Despite these caveats, the agent or supervisor can continue to perform
normal operations on the phone. Desktop behavior returns to normal after the
agent or supervisor drops off the conference call.
AWDB failover
The prerequisites for AWDB failover are as
follows:
The secondary Administrative Workstation
Database (AWDB) is configured.
Agents and
supervisors are authenticated against the AWDB database. When an agent or
supervisor makes a successful API request (such as a sign-request or call
control request), the credentials are cached in Finesse for 30 minutes from the
time of the request. After a user is authenticated, that user continues to be
authenticated until 30 minutes pass, even if both AWDBs are down. Finesse
attempts to reauthenticate the user against the AWDB only after the cache
expires.
If Finesse loses connection to the primary Administration & Data server,
and the preceding prerequisites have been implemented, AWDB failover occurs.
After Finesse loses connection to the primary Administration & Data server, it tries to reconnect to the
secondary server. If Finesse cannot connect to any of the Administration & Data servers and the cache
has expired, the system returns a 401 "Unauthorized" HTTP error message.
Finesse repeats this process for every API request until it can connect to one of the Administration & Data servers. During failover, Finesse does
not process any requests, but clients can still receive events.
Finesse client failover
With a two-node Finesse
setup (primary and secondary Finesse servers), if the primary server goes out of
service, agents who are signed in to that server are redirected to the sign-in
page of the secondary server.
Client failover can occur for the
following reasons:
The Cisco Tomcat Service goes down.
The Finesse
Webapp Service goes down.
The Cisco Notification Service
goes down.
Finesse loses connection to both CTI
servers.
Desktop behavior
Under certain conditions, Finesse sends a forced logout with a reason
code of 255 to the CTI server. The actual behavior of the desktop under these
conditions depends on the setting for Logout on Agent Disconnect (LOAD) in
Unified CCE.
The following table lists the conditions under which Finesse sends a
forced logout to the CTI server:
Scenario
Desktop Behavior
Server Action
Race Conditions
The client closes, the browser crashes, or the agent clicks the
Back button on the browser.
When you close the browser or navigate away from the Finesse Desktop, the Finesse Desktop makes a best-effort attempt to notify the server.
Finesse receives a presence notification of
Unavailable from the client. Finesse waits 10 seconds, and
then sends a forced logout request to the CTI server.
The agent closes the browser window. Finesse receives a
presence notification of Unavailable for the user. Finesse tries to sign the
agent out; however, that agent is already signed out.
If the browser crashes, it can take the Finesse server up to
60 seconds to detect that the client is gone and send a presence notification
to Finesse. A situation can occur where the client signs in to the secondary
Finesse server before the primary Finesse server receives the presence
notification caused by the browser crash. In this case, the agent may be signed
out or put into Not Ready state on the secondary Finesse server.
If the Finesse Desktop is running over a slower network connection, Finesse may not always receive an Unavailable presence notification from the client browser. In this situation, the behavior mimics a browser crash, as described in the preceding condition.
The client refreshes the browser
—
Finesse receives a presence notification of
Unavailable from the client. Finesse waits 10 seconds
before sending a forced logout request to the CTI server to allow the browser
to reconnect after the refresh.
—
The client encounters a network glitch (Finesse is in service)
Because the connection to the Finesse server temporarily goes
down, the client fails over to the secondary Finesse server.
The primary Finesse server receives a presence notification of
Unavailable from the client. Because Finesse is in service, it sends a forced
logout request to the CTI server for the agent.
A situation can occur where the forced logout does not happen
before the client signs in to the secondary Finesse server. If the agent is on
a call, the primary Finesse server sends the forced logout request after the
call ends. The agent will be signed out or put into Not Ready state when the
call ends, even though the client is already signed in to the secondary Finesse
server.
Feedback
