Cisco CTI software provides an interface between the Unified ICM
software and agent desktop and server applications. The CTI software works with
a Peripheral Gateway's ACD and IVR interface software and associated ACDs
to track call events and transactions and forward call- and transaction-related
data to an agent's desktop computer.
Pre-installation planning for CTI involves several tasks:
Review CTI Server communications and platform options.
Become familiar with the desktop options available with CTI Server.
Estimate CTI message traffic.
Plan fault tolerance for the CTI Server.
Review ACD support for client control and third-party call control.
CTI Server, the basic server component of Cisco CTI, enables the
Unified ICM software to deliver agent, call, and customer data in real-time to
a server and/or workstation application as events occur throughout the life of
a call. The CTI Server is a software process that runs on a Peripheral Gateway
(PG). It is the CTI gateway into the Unified ICM software's data and services.
The following figure shows a sample CTI Server system. CTI Servers may
be running at one or several call centers in the enterprise.
Figure 1. CTI Server Overview
One function of the CTI Server is to forward pre-route indications to
CTI application servers. Pre-route indications identify the caller and provide
CTI applications with other call attributes while the call is still in the
public or private network (that is, before the call is connected to an agent or
CTI Server also reports call events and agent work state changes as
they occur through each stage of the call flow—from the moment a call arrives
at an answering resource (ACD, PBX, IVR), until the caller hangs up. In a
desktop application environment, call event information is delivered to the
targeted agent desktop at the same time the call is delivered.
The CTI Server uses TCP/IP Ethernet for communication with clients.
You can use multi-protocol IP routers to provide connectivity to clients on
other types of LANs. You can use the same LAN for the Peripheral Gateway's
visible network interface and for CTI client-to-server communications.
CTI Server platform options
The CTI Server runs on a machine that is also running a Cisco ACD (or
VRU) PG process. The shared platform option is shown in the following figure.
Figure 2. Shared CTI Server Platform
CTI Server fault tolerance
You can implement the CTI Server in a duplexed, fully fault-tolerant
configuration. In a duplexed configuration, the CTI Server is installed on a
pair of server platforms. In the event of a failed CTI client connection, the
client process can automatically reestablish a connection to either side of the
duplexed CTI Servers. The call's CTI client history list and any updates to
call variables remain in effect when the connection is reestablished. The
following figure shows a duplexed CTI Server configuration.
Figure 3. Duplexed CTI Server
Cisco CTI Object Server (CTIOS)
CTI Object Server (CTIOS) is a high-performance, scalable,
fault-tolerant server-based solution for deploying CTI applications. CTIOS
serves as a single point of integration for third-party applications, including
Customer Relationship Management (CRM) systems, data mining, and workflow
Configuration data is managed at the server, which helps simplify
customization, updates, and maintenance of CTI applications. You can access and
manage servers remotely. Thin-client and browser-based applications that do not
require Cisco software on the desktop can be developed and deployed with CTIOS.
CTIOS incorporates the following major components:
Client Interface Library
CTIOS Combo Desktop for Agents and Supervisors
CTIOS is a client of CTI Server. It has a single all-events connection
to Cisco CTI Server. In turn, CTIOS accepts client connections using session,
agent, and call interfaces. These interfaces are implemented in .NET, COM,
Java, C++, and C, allowing for a wide range of application development uses.
The interfaces are used for call control, to access data values, and to receive
For complete and current information about the number of agents
supported for CTIOS and other hardware configurations, see the
Hardware & System Software Specification (Bill of Materials) for
Cisco Unified ICM/ContactCenter Enterprise & Hosted.
For new installations, the CTIOS Server should be co-resident with the
For more information on CTIOS, refer to the Cisco Unified ICM Software
CTIOS document set.
CTI Server client application models
You can use either of two client models to integrate
call center applications with the Unified ICM: agent workstation and CTI
In the agent workstation model, the client is an application running
on a personal computer on an agent's desktop. This client is interested in
the call data and call events related to a single agent teleset. The agent
workstation application can also be interested in agent state changes.
Typically, when the agent workstation application is informed of an
incoming call, it uses the call data collected by the Unified ICM system to
retrieve caller-specific data from a database. This data is presented on the
agent workstation screen at approximately the same time that the incoming call
is connected to the agent.
While handling the call, the agent can update some of the call data.
For example, an agent who is processing an insurance claim can make some
adjustments to the call data; an update ensures that the changes are not lost
before the call is transferred to a second agent.
Upon completion of the call, the agent can use the client to add
call-specific, wrap-up information to the Termination_Call_Detail record logged
in the Unified ICM central database. This wrap-up data is a key value that can
help locate more detailed transaction information in some other database. If
the agent conferences with or transfers the call to another agent on the same
ACD with a CTI client workstation, then that agent's CTI client also
receives the incoming call data, including any updates made by the first agent.
If the transfer or conference involves an agent on another ACD, the call data
is provided to the remote CTI client if a translation route is used.
CTI bridge application
CTI Bridge applications are interested in all call and agent state
events that occur on the ACD, unlike agent workstation applications that are
interested only in the events associated with a particular teleset. The CTI
Bridge application is a user-written program that converts or adapts some or
all of the CTI Server messages into another format; a single CTI Bridge
application provides such services for multiple agent desktops. You can design
the CTI Bridge application to interface with CTI Servers or similar
applications on systems that are already in use in the call center.
Some examples of CTI Bridge applications include:
Message converter applications. For example, an application can
convert the CTI Server message set to the message set of a foreign telephony
Server-to-server communication applications. For example, an
application can enable the CTI Server to speak directly to a help desk
application's middle tier server.
In a CTI Bridge configuration, a CTI Bridge application provides
the connection between an existing desktop CTI application and the Unified ICM.
Figure 4. CTI Bridge Model
All of the functionality found in the agent workstation (desktop)
model is also available in the CTI Bridge application model. However, you must
write the CTI Bridge application to support this functionality.
CTI Server network and database planning
Some pre-installation planning is
necessary to prepare your CTI desktop and network environment for the
introduction of a CTI Server.
The machine running CTI Server connects to the
CTI desktop environment via an Ethernet LAN. Therefore, the CTI desktop
environment must reside on an Ethernet LAN. Other networks, such as Token-Ring,
can require additional network hardware if you are connecting them to a CTI
Be sure that the CTI
desktop environment IP routing scheme is compatible with the Unified ICM system
and CTI Server. For example, if you have a firewall set up on the CTI
environment LAN, you may need to change your system access setup or network
Software distribution strategy
If you are installing the
CTIOS or CTI Desktop software components on multiple desktops, you must create
a distribution strategy. For example, if you place the software on a
centralized server and allow certain desktops within the enterprise to download
the software, you must ensure that all sites have access to the centralized
Well-known port for CTI Server
A well-known port number identifies CTI Server as an application
running in your intranet. All CTI clients, as well as the system administrator,
must know this well-known port number. If you do not want to use CTI
Server's default port numbering scheme, you can choose a well-known port
number that fits into your overall network environment. You can use the
Peripheral Gateway Setup to override the default port settings used to install
the CTI Server PGs.
Fail-over strategy for CTI clients
Cisco CTI includes automatic fail-over and
recovery mechanisms. Ensure that each CTI client has a clear and established
network path to a CTI Server in case of a fail-over. For example, you may plan
for each CTI client to have access to local and remote CTI
You may have CTI applications that perform database queries to
retrieve customer information for use in call processing. Some CTI applications
acquire database records
"pre-call" (that is, before the call arrives at an agent's
desktop). Other applications query a database immediately after the call
arrives at the agent's deskset. Plan a strategy for executing database
queries in the most efficient and timely manner possible.
CTI Server messages
The CTI Server makes traffic call data available to
applications in real time. To accomplish this task, the CTI Server responds to
requests from clients and originates unsolicited messages. All messages share a
common message header and use the same set of data types.
table titled CTI Server Message Categories groups the messages
into broad categories based on the nature of the message data.
Table 1 CTI Server Message Categories
Messages related to the establishment and
maintenance of a client connection to the CTI Server. These messages typically
happen at client startup, shutdown, and during
to system-level events on the PG (for example, peripheral offline, loss of
PG-to-central controller communications).
Messages related to call state changes.
Messages related to agent state changes.
Call Data Update
Messages related to CTI client modification of call
Messages related to the
direct control of agent state (for example, sign-in, sign-out) as well as
control of inbound and outbound
CTI Server imposes
varying degrees of message traffic against the PG based on the specific call
center and CTI application environment in which it is deployed. Document a
typical call scenario in your CTI application environment, prepare for adequate
bandwidth, and order the proper server platform.
For a description
of the session management messages, see the latest version of the
Cisco Unified ICM Software CTI Server Message Reference
To estimate CTI
Server message traffic, document a typical call scenario in your CTI
application environment. The goal of this exercise is to account for all types
of potential message traffic in the link between the CTI Server and the CTI
For example, you can handle a
typical call as follows:
The call is
The call receives a call treatment such as a
request to set call data.
A simple call release, hold,
transfer, or post-route request takes place.
time an agent state may change (for example, from ready to work
Message load and bandwidth
Ensure that you have enough bandwidth in the
datacom connection to handle the message traffic between the CTI Server and the
CTI application environment. For example, are you sure that a 56-Kbps
connection is adequate for your environment?
The call scenario
process helps you to estimate the message load and calculate how much bandwidth
is required in the link between the CTI Server and the CTI application
environment (for example, 56K, 256K, or more).
CTI Server platform
Ensure that the CTI Server platform has adequate
CPU processing speed and RAM to handle the message activity. You may require a
high-end Cisco CTI Server/PG platform for the CTI
Third-party call control
Call control is the ability of an application that is external to the
ACD to programmatically control a telephone call. For example, a CTI
application can put a call on hold, transfer the call, or hang up the call.
With first-party call control, the CTI application can control only
the teleset that is physically connected to the computer running the CTI
application. First-party call control requires a physical connection between
the computer and the telephone and other add-on hardware (see the following
Figure 5. Desktop First-Party Call Control
CTI Server products support third-party call control. Any call control
initiated outside the ACD/teleset domain is referred to as third-party. With
third-party call control, there is no physical connection between the computer
and the teleset (see the following figure).
Figure 6. Desktop Third-Party Call Control
The desktop CTI application communicates with the Cisco CTI Server
over a LAN. The CTI Server in turn communicates with the ACD to send call
control requests. In this model, the CTI application is not bound to any
particular teleset. The CTI application can control any teleset connected to
the ACD and CTI Server.
Most, but not all, ACDs support third-party call control.
Depending on the specific ACD, the client application can perform all
or most of the following telephony functions:
Agent Login and Wrap-up data
Generate DTMF tones
Get/Set Agent states
Get/Set ICM call data (ANI, DNIS, CED, UUI, call vars)
Make a call
ACD support for client and third-party call control
Different peripheral types
implement and support varying levels of CTI functionality. For example, a
different set of client control requests and call event types are available
depending on the peripheral type. In addition, there can be other CTI-related
restrictions and implementation differences based on the type of peripheral.
Consider these differences when you write a CTI client application that
interfaces with third-party switches and devices.
The Rockwell Galaxy does
not have CTI Server support.
The Siemens Rolm 9751 CBX
does not have CTI Server support, but does support screen-pop
As part of CTI pre-installation planning,
review ACD support for client control and third-party call