Cisco Cisco Computer Telephony Integration OS 8.5 Developer's Guide
2-4
CTI Server Message Reference Guide (Protocol Version 9) Release 7.0(0)
Chapter 2 CTI Client Application Guidelines
CTI Server Operations During 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 ICM release in a controlled environment prior to
upgrading production systems with the new ICM release, 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 ICM release in a controlled environment prior to
upgrading production systems with the new ICM release, 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 ICM Failures
The ICM system 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 ICM system 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 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 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 ICM Peripheral Gateway and the ICM central controller does
not prevent event messages, however, the failure does prevent use of the ICM post-routing and
translation-routing features.
not prevent event messages, however, the failure does prevent use of the ICM post-routing and
translation-routing features.