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.

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.

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.

CTI Object Server (CTI OS) is a high-performance, scalable, fault-tolerant server-based solution for deploying CTI applications. CTI OS serves as a single point of integration for third-party applications, including Customer Relationship Management (CRM) systems, data mining, and workflow solutions.

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 CTI OS.

CTI OS incorporates the following major components:

• CTI OS Toolkit

• Client Interface Library

• CTI OS Combo Desktop for Agents and Supervisors

CTI OS is a client of CTI Server. It has a single all-events connection to Cisco CTI Server. In turn, CTI OS 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 event notifications.

For complete and current information about the number of agents supported for CTI OS and other configurations, see the Solution Design Guide for Cisco Unified Contact Center Enterprise at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-implementation-design-guides-list.html. See Virtualization for Unified Contact Center Enterprise at http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-unified-contact-center-enterprise.html for hardware requirements for Unified CCE virtualized systems.

For all installations, the CTI OS Server must be co-resident with the PG.

For more information on CTI OS, refer to the CTI OS document set.

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

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

  

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

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 application environment.

For example, you can handle a typical call as follows:

• The call is pre-routed.

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

• During this time an agent state may change (for example, from ready to work ready).

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

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