Cisco Cisco IPCC Web Option Leaflet
7-21
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 7 Cisco Unified Expert Advisor Option
Recommendations for Deploying Unified Expert Advisor
High Availability for Microsoft Office Communicator Server
The federation link between Cisco Unified Presence and Microsoft Office Communications Server
(OCS) is not a redundant link. Only one Cisco Unified Presence server in a cluster may link to the OCS.
If that Cisco Unified Presence server fails or loses its connection, there is no backup path.
(OCS) is not a redundant link. Only one Cisco Unified Presence server in a cluster may link to the OCS.
If that Cisco Unified Presence server fails or loses its connection, there is no backup path.
Recommendations for Deploying Unified Expert Advisor
Follow the guidelines and best practices in this section when deploying Unified Expert Advisor.
Using Router Requery
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.
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.
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.
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.
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.
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.
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.
Recovery Following a Failover
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.
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.