Cisco Cisco Unified Contact Center Enterprise 9.0(1) Guia Do Desenho

Follow the guidelines and best practices in this section when deploying Unified Expert Advisor.

In deployments that include Unified CVP, it is possible for failed calls to reach expert advisors for 
various reasons to invoke a requery to Unified CCE, which then allows the Unified CCE routing script 
to control how the call is handled when such a failure occurs. In order to take advantage of this capability, 
check the Enable Requery check box in the script’s Queue to Skill Group node. Doing so causes an “X” 
branch connector to appear on the node. Calls that successfully reach their destinations normally 
terminate in the Queue node, but calls that are requeried proceed through that “X” branch to a subsequent 
node.

The script can determine, by examining a script editor variable, whether the call was requeried due to 
no-answer, busy, or other connection failure. It may be appropriate at that point to requeue the call by 
connecting the branch to another Queue node.

If your deployment employs this requery capability, then consider the following notes:

In general, the second queue node should be different than the first, such as by including more or 
different skill groups. Otherwise, the call is likely to encounter the exact same result as with the first 
queue node.

For the same reason, be careful about looping the script back to the first queue node. It is important 
to change something, so that the result will be different.

For sizing purposes, remember that each time a queue node sends the call to Expert Advisor, it 
appears as a new call to the system. Therefore, the total number of calls reaching Expert Advisor 
per unit of time, is the number of actual incoming calls plus the number of calls returned to Expert 
Advisor through requery.

Expert Advisor itself is not aware of which calls are requeried instances of previous calls. However, 
it is possible to find such calls in the logs and the historical database because they appear with 
different ContactIds but the same GUID and the same Unified CCE Router Call Key.

If Runtime Server A loses power or otherwise fails over to Runtime Server B, then all new calls are 
handled by Runtime Server B. If at some point Runtime Server A comes back up, it will remain in Partial 
Service and Runtime Server B will continue to be the active system. Runtime Server A becomes active 
again only if you manually shut down Runtime Server B or if it encounters some sort of fault of its own 
that causes it to fail.

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.)