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.

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.

The prerequisites for AWDB failover are as follows:

• The secondary Administrative Workstation Database (AWDB) is configured.

• The secondary AWDB host is configured through the Finesse administration console.

Agents and supervisors are authenticated against the AWDB database. When an agent or supervisor makes a successful API request (such as a sign-in 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.

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.

With a two-node Finesse setup (primary and secondary Finesse servers), if the server that an agent is connected to goes out of service, the agent receives a notification that the connection with the server was lost. The Finesse desktop does the following:

• The Finesse desktop continues to check whether the current Finesse server recovers its state.
• The Finesse desktop checks if the other Finesse server is available and in service.

If the other Finesse server is available, the desktop automatically signs the agent into the other server. If the current Finesse server recovers its state, the desktop notifies the agent that it has reconnected.

The Finesse smarter failover logic has three triggers to detect desktop failure:

• The Finesse desktop receives a SystemInfo event that the current server is OUT_OF_SERVICE.

• The BOSH connection is disconnected.

• The "finesse" XMPP user presence changes to unavailable.

No matter which trigger is detected, the desktop reconnection logic is as follows:

1. Poll SystemInfo for current server every 20 seconds and the other Finesse server between 10-45 seconds.

2. If SystemInfo is IN_SERVICE, check the BOSH connection.

3. If BOSH is disconnected, make a BOSH connection request

4. If BOSH is connected and the server is IN_SERVICE, refresh the data.

While polling SystemInfo every 20 seconds, the desktop also checks the availability of the alternate server every 10-45 seconds. The smarter failover logic is biased toward staying with the current server. If the failover logic detects that the alternate server is available, it checks the current server one more time. If the current server has recovered, the desktop reconnects to the current server. If the current server is still down, the desktop connects the agent to the alternate server. In this case, the agent does not automatically reconnect to the failed server after it recovers but instead remains connected to the alternate server.

If the BOSH connection is the source of failure, the JabberWerx library makes three attempts to reconnect before changing the state of the desktop to disconnected. These attempts occur before the smarter failover logic begins.

Client failover can occur for the following reasons:

• The Cisco Tomcat Service goes down.

• The Finesse Webapp Service goes down.

• The Cisco Finesse Notification Service goes down.

• Finesse loses connection to both CTI servers.

  Note	After Finesse failover, the pending state of an agent will not be displayed once the agent fails over to the secondary Finesse node. The pending state change is reflected on the desktop only after the call ends.

Under certain conditions, Finesse sends a code of 255 to the CTI server (you may see a different code on the CTI server side). The actual behavior of the desktop under these conditions depends on the setting for Logout on Agent Disconnect (LOAD) in Unified CCE. By default, the CTI server places the agent in Not Ready state.

Note	Finesse takes up to 120 seconds to detect when an agent closes the browser or the browser crashes and Finesse waits 60 seconds before sending a forced logout request to the CTI server. Under these conditions, Finesse can take up to 180 seconds to sign out the agent.

The following table lists the conditions under which Finesse sends this code to the CTI server: