Cisco Cisco IPCC Web Option Leaflet

Runtime server failover relies heavily on the Unified ICM PG's guarantee that it will connect to only one 
peripheral at a time. Therefore, each runtime server knows it is active if and only if it has an active 
connection from the Unified ICM PG. There are, in fact, no heartbeats or other direct communications 
between the two runtime servers, nor are there any heartbeats or other direct communications between 
the idle side PG and the inactive runtime server.

Each PG and its corresponding runtime server, therefore, fail-over in tandem. If the active runtime server 
fails or is manually taken out of service, then it disconnects itself from its PG, and Unified ICM causes 
the standby runtime server's PG to become active. That PG then establishes a connection to the standby 
runtime server, which causes the standby runtime server to become active.

Similarly, if one PG fails over to its standby counterpart, the corresponding runtime servers fail-over as 
well.

The disposition of calls upon failover depends on the cause of failover. On the one hand, it could be a 
software failover, either because the active node is being shut down manually or because of a software 
failure of some kind. On the other hand, it could be a hardware failover due to either a hardware or 
network outage. An operating system level restart also acts like a hardware failover. The following table 
shows the distinction between these two failover modes.

"In-flight" calls are those that have been received by the Unified Expert Advisor runtime server but have 
not yet been connected to an expert advisor.

Expert advisors log their presence clients into Cisco Unified Presence, not to Unified Expert Advisor, 
so the presence clients are not affected by a failover. They will, however, receive a Message Set message 
indicating that there was a technical problem and warning them about conducting call control operations. 
The standby runtime server automatically takes over the job of managing each advisor's agent state with 
respect to Unified ICM; however, it does not know which advisors are already talking to callers. 
Therefore it is possible that some advisors are assumed to be ready and available, and could receive 
pop-up task offers when they are already on a call, just as they might when talking on the phone for any 
reason unrelated to Expert Advisor activity. Advisors are of course free to ignore or decline such offers.

All new calls are routed to the standby server.

All new calls are routed to the standby server.

All existing, connected calls remain fully 
operational until completed.

All existing, connected calls remain connected 
until completed, but call control operations such 
as transfer and hold can cause the call to drop, in 
which case Unified CVP would issue a 
Unified ICM re-query.

"In-flight" calls continue normally on the formerly 
active server as long as there is a possibility that 
any advisor has been offered the task. If not, they 
are rejected and Unified CVP issues a 
Unified ICM re-query. If Unified CVP is not part 
of the deployment, then a SIP error code is 
returned to the SIP user agent that sourced the call.

"In-flight" calls time-out at Unified CVP, and a 
Unified ICM re-query is invoked. If Unified CVP 
is not part of the deployment, then it is up to the 
SIP user agent that sourced the call to implement 
its own time-out mechanism.