Cisco Cisco IP Contact Center Release 4.6.1 Dépliant

After Runtime Server A has failed over to Runtime Server B, the administrator should make every effort 
to bring Runtime Server A up again as soon as possible. Once Runtime Server A is running properly, the 
administrator should manually shut down Runtime Server B, which will cause Runtime Server A to 
become active again.

It is generally better to have the primary runtime server be the active runtime server because new calls 
always try to go to Runtime Server A before they try Runtime Server B (per the static route 
configuration in the SIP proxy server), and a delay is possible. If Runtime Server A is running, even if 
it is not active, then the delay is very slight and probably not noticeable. But if Runtime Server A is 
down, then the delay involves a time-out and could amount to a few seconds and be noticeable by callers. 
(The time-out is configurable in the Cisco Unified Presence proxy server service parameters.)

In cases where Runtime Server A is expected to be down or disconnected for an extended period of time, 
it would be best to reverse the priorities in the SIP proxy server's static route table so that the backup 
runtime server rather than the primary runtime server receives the first invite. It is important to 
remember to restore the original priorities once the primary server is back online.

Another important reason to get the primary runtime server up and running as soon as possible is that 
OAMP is accessible as long as the primary runtime server is running, even if it is in Partial Service. 
There is currently no way to promote the backup runtime server to primary.

When you configure the method in which calls are delivered from Cisco Unified CM to Unified CCE, 
you have two decisions to make. First, do you configure the dialed number to go through a route pattern 
via a SIP trunk to Unified CVP, or do you configure it to go through a route point to Unified ICM? 
Second, once the call reaches Unified ICM and begins a routing script, do you force it to transfer to 
Unified CVP even if no queuing is required?

This section discusses the trade-offs involved.

If the call is routed through a route point, if the routing script does not contain any SendToVRU node 
or RunExternalScript node prior to the Queue node, and if expert advisors are available in the 
referenced skill groups (meaning no queueing is necessary), then the SIP Invite will flow from Cisco 
Unified CM directly to Unified Expert Advisor and will bypass Unified CVP. This means that 
Unified CVP ports will not be tied up unnecessarily, but the extra functionality that Unified CVP 
provides (such as simulated ring tone, re-query in case of failure, and re-query in case of time-out) 
will not be available.

If any of the above conditions is not true, then a SIP dialog will be established between Cisco 
Unified CM and Unified CVP, and another SIP dialog will be established between Unified CVP and 
Unified Expert Advisor. All the Unified CVP functionality is available in this case, but be aware 
that one Unified CVP port and license remain tied up through the life of the call (until both the caller 
and the expert advisor disconnect).

In addition, the call should always be routed through a route point if it is coming from a Unified CCE 
agent in the form of a consult, conference, or transfer. This allows Unified CCE to track this call as a 
part of the original call that is being handled by the Unified CCE agent.

Given these trade-offs, the best practice in most cases is for the call to be routed through a route point 
first, but for the routing script to include at least a SendToVRU node prior to the Queue node. This 
provides the best reporting and the best call handling functionality, but at the expense of the possibly 
unnecessary use of a Unified CVP port license for the life of the call.