Cisco Cisco Computer Telephony Integration Option 8.5 Reference Guide
2-4
CTI Server Message Reference Guide (Protocol Version 14) for Cisco Unified ICM/Contact Center Enterprise & Hosted
Release 8.0(1)
Chapter 2 CTI Client Application Guidelines
CTI Server Operations During Unified ICM Failures
This defect no longer exists in CTI Server Protocol Version 5 and subsequent releases. However, existing
CTI client applications may be inadvertently dependent upon the old (incorrect) behavior and may no
longer function correctly even though they continue to use the older CTI Server protocol revision. You
should retest all CTI Server applications with the new release in a controlled environment prior to
upgrading production systems with the Unified ICM, to avoid any impact to normal business operations.
CTI client applications may be inadvertently dependent upon the old (incorrect) behavior and may no
longer function correctly even though they continue to use the older CTI Server protocol revision. You
should retest all CTI Server applications with the new release in a controlled environment prior to
upgrading production systems with the Unified ICM, to avoid any impact to normal business operations.
CTI applications that use only the BEGIN_CALL_EVENT, CALL_DATA_UPDATE_EVENT, and
END_CALL_EVENT call event messages may not require any changes. CTI applications that use the
ConnectionID field in any other call event messages will almost certainly be affected.
END_CALL_EVENT call event messages may not require any changes. CTI applications that use the
ConnectionID field in any other call event messages will almost certainly be affected.
For further call ConnectionID details, see “
” in Chapter
.
CTI Server Operations During Unified ICM Failures
The Unified ICM is fault tolerant and recovers from failures quickly, but certain types of failures are not
transparent and require consideration during application design:
transparent and require consideration during application design:
•
A failure of the active CTI Server causes all client connections to be closed. Clients may reconnect
immediately (to the other side’s CTI Server in duplex configurations, or to the restarted CTI Server
in simplex configurations), but clients will not receive messages for events that occurred while the
client session was not open. ClientEvent clients will receive a BEGIN_CALL_EVENT for all calls
that are already in progress when their session is opened.
immediately (to the other side’s CTI Server in duplex configurations, or to the restarted CTI Server
in simplex configurations), but clients will not receive messages for events that occurred while the
client session was not open. ClientEvent clients will receive a BEGIN_CALL_EVENT for all calls
that are already in progress when their session is opened.
•
A failure of the data link or related software between the ACD and the Unified ICM will cause
applications not to receive event messages for the duration of the outage. This type of failure is
reported to all CTI clients via a SYSTEM_EVENT indicating that the peripheral (ACD) is offline.
In addition, the Unified ICM may take additional action depending upon the type of failure and the
ACD involved. In many cases, an END_CALL_EVENT will be sent immediately for every call that
was in progress, even though the actual voice calls may still be in progress. When normal operation
is restored, calls that are in progress may or may not have their call events reported, depending upon
the particular type of ACD. If so, a new BEGIN_CALL_EVENT is sent for each call that will have
event reporting resumed. In other cases, the calls will be allowed to linger for a short time after the
failure without sending an END_CALL_EVENT. If the data link is restored within the short time
interval, normal call event reporting continues (although events that occurred during the outage are
not reported and the call may now be in a different state). If normal operation is not restored within
the allotted time an END_CALL_EVENT is then sent for each call.
applications not to receive event messages for the duration of the outage. This type of failure is
reported to all CTI clients via a SYSTEM_EVENT indicating that the peripheral (ACD) is offline.
In addition, the Unified ICM may take additional action depending upon the type of failure and the
ACD involved. In many cases, an END_CALL_EVENT will be sent immediately for every call that
was in progress, even though the actual voice calls may still be in progress. When normal operation
is restored, calls that are in progress may or may not have their call events reported, depending upon
the particular type of ACD. If so, a new BEGIN_CALL_EVENT is sent for each call that will have
event reporting resumed. In other cases, the calls will be allowed to linger for a short time after the
failure without sending an END_CALL_EVENT. If the data link is restored within the short time
interval, normal call event reporting continues (although events that occurred during the outage are
not reported and the call may now be in a different state). If normal operation is not restored within
the allotted time an END_CALL_EVENT is then sent for each call.
•
A failure of the datalink between the Unified ICM Peripheral Gateway and the Unified ICM central
controller does not prevent event messages, however, the failure does prevent use of the Unified ICM
post-routing and translation-routing features.
controller does not prevent event messages, however, the failure does prevent use of the Unified ICM
post-routing and translation-routing features.