Product Offering Descriptions (Release 4.6)

Table Of Contents

Product Offering Descriptions

Sample Code and Utilities

Cisco CTI Server

Cisco CTI Object Server (CTI OS)

CTI Desktop

CTIClient

Desktop Control Server

Softphone Controls and CTI Desktop Softphone

CTI Desktop Softphone

AgentStatistics

SkillGroupStatistics

Flexibility of Softphone Controls

COMMonitor

JavaClient

Cisco Turnkey CTI

Product Offering Descriptions

---

This chapter provides brief descriptions of the various Cisco CTI product offerings, including comments on when and why one of these offerings might be preferred to another. This chapter discusses the following:

•Sample code and utilities

•Cisco CTI Server

•Cisco CTI Object Server (CTI OS)

•CTI Desktop, which includes: CTI Desktop Softphone, Softphone Controls, COMMonitor, Desktop Control Server, and CTIClient

•JavaClient

•Cisco Turnkey CTI

For detailed discussions of each of the above components, see the documentation referred to in the various sections.

All of the product offerings provide third-party call control support. Depending on the specific switch, the client application can perform all or most of the following telephony functions:

•Answer/Hang Up

•Make a Call

•Hold/Retrieve

•Redirect

•Transfer (single step and consultative)

•Conference (single step and consultative)

•Generate DTMF Tones

•Get/Set Call Data

•Agent Login, Wrap-up, and Logout

•Get/Set Agent States

Sample Code and Utilities

An overarching goal of the Cisco CTI offerings is to allow customers to get up and running very quickly. While Cisco provides a number of manuals that describe in detail the various CTI product offerings, developers do not usually want to read through lengthy documents. Rather, they like to have working example code that demonstrates in code how to make things happen. Through the sample code, Cisco provides working examples in a variety of languages; e.g., Visual Basic, Visual C++, Delphi, PowerBuilder, and VB Script inside a Web browser. This code is provided without copyright so that you are free to copy and use the code within your own projects. All this is provided as a means to get your CTI project working at the earliest possible date. The code samples are provided in appropriately named directories on the Cisco CTI Desktop CD.

Utilities are also provided to aid in development. These utilities—such as CTISim and CTITest—are documented in the Cisco ICM Software CTI Programmer's Guide.

Cisco CTI Server

Cisco CTI Server, the basic server component of Cisco CTI, enables 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 either on a Peripheral Gateway (PG) or on a CTI Gateway (CG) machine. It is the CTI gateway into ICM software's data and services.

•Pre-route indications identify a caller and provide associated attributes to applications while the call is still in the public or private network and before the caller is connected to an agent, Web server or IVR.

•Call events are provided throughout all stages of the call flow, from the moment a call arrives at an answering location (ACD, PBX, IVR, Web server) until the caller hangs up.

---

Note Agent work state changes are reported as they occur.

---

The system's full third-party call control features allow agents and integrated desktop or server applications to perform such tasks as transfer, conference and set call data, all within an enterprise framework. Data collected by an agent at the desktop can be transferred among agents across multi-vendor switches, allowing customer and transaction data to accompany a call from the IVR or Web server to the agent, and from site-to-site, as required. This capability increases the efficiency of a virtual call center workforce by eliminating time spent verbally soliciting information that should already be available.

You may write to the CTI Server directly. However, first consider one of the Cisco provided application-directed offerings (CTI OS Toolkit, JavaClient).

For more on the CTI Server, see the Cisco ICM Software CTI Server Message Reference Guide.

Cisco CTI Object Server (CTI OS)

CTI Object Server (CTI OS) is a high performance, scalable, fault-tolerant server-based solution for deploying CTI applications. It is Cisco's latest version of CTI implementation. 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 and behavior information is managed at the server, simplifying customization, updates, and maintenance. Servers can be accessed and managed 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 Agent Phone

•CTI OS Supervisor Phone

CTI OS, a client of CTI Server, 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 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. The client interface supports the following:

•Extensibility. The interface is designed so that it can be easily extended. (New functionality in future revisions will not obsolete the current interfaces.)

•Simplicity and ease of use. Each method supports a variable number of arguments. This simplifies the use of optional arguments.

•Subclassable object architecture. Subclassing allows customers to create custom-defined call or agent object in addition to or instead of Cisco-defined objects. This is a powerful mechanism that gives a client application complete control over all events and responses.

•Automatic failover of client connections.

•Multi-threaded and thread-safe architecture. An application can spawn multiple threads using a single connection (session) object.

•Portability to multiple platforms and containers. Applications can be deployed on virtually any platform and any host container, such as VB, PowerBuilder, or Siebel.

•Thin client, browser-based applications deployed using JavaScript and Java.

The advantages of using CTI OS for integrations are:

•Multiple programmatic interfaces available. Developers can choose to develop to a Java, COM, C, or C++ interface.

•Enables developers to build applications that can monitor or control more than one agent. With the Event Filter inherent in CTI OS, supervisory applications are written much more easily than with any other Cisco CTI product.

•Facilitates server-to-server integration. Developers using CTI OS have access to data from CTI Server without the need to write to CTI Server's native socket API.

•Reduces the need to account for switch-specific behavior. Switch-specific logic resides in the CTI OS server component, so developers writing to CTI OS need not concern themselves with case programming for their specific switch types.

•Facilitates thin client, browser-based integrations. Developers desiring an entirely browser-based or thin client desktop can utilize CTI Object Server to integrate with Application Servers or other hosts, which does not require any Cisco software on the desktop.

CTI Desktop

CTI Desktop is an earlier version CTI package that consists of the following major components.

•CTIClient

•Desktop Control Server (DCS)

•Softphone Controls

•CTI Desktop Softphone

CTI Desktop supports client applications that meet the following requirements:

•Written in any language that supports the Microsoft Component Object Model (COM) binary interface. This includes low order languages (for example, Visual C++) and high order languages (for example, Visual Basic or PowerBuilder). Also supported is scripting performed within a host container application.

•Client applications can run on any platform that supports the OLE2 protocol (for example, Visual Basic or Internet Explorer).

---

Note Currently CTI Desktop requires that a client application must be a desktop application handling a single teleset. It cannot be a CTI Bridge application.

---

CTIClient

CTIClient acts as middleware between the CTI Server interface and a host application at the desktop. Its purpose is to make it easy for business application developers to integrate with ICM software.

CTIClient is a packaging of the CTI Server interface, with additional built-in support for high availability with automatic recovery mechanisms for CTI Server failover. You do not need to understand the details of the CTI Server messages or invent new software to perform the low-level tasks of network communication and variable length packet handling. Figure 4-1 depicts where CTIClient sits in relation to the CTI Server and in relation to the client OLE application. (Also see Figure 4-2, for CTIClient as a part of DCS.)

Figure 4-1 CTIClient Architecture

CTIClient is termed middleware because it sits between the client application and the CTI Server interface. To the CTI Server, CTIClient acts as a client; to the client application, CTIClient acts as an in-process (that is, a DLL) ActiveX server. CTIClient handles both inbound and outbound traffic and supports multiple call appearances on a single teleset.

Some advantages to using CTIClient directly rather than using DCS are:

•CTIClient (a DLL) runs within a host application; that is, it is an in-process server. As such, calls from the host (or containing) application to the methods (functions) exposed by CTIClient operate slightly faster than calls to DCS because they do not have to cross process boundaries.

•CTIClient uses fewer resources than DCS since it performs fewer functions.

For more information on CTIClient, see the Cisco ICM Software CTIClient Reference Guide.

Desktop Control Server

The Desktop Control Server (DCS) is a local COM server that runs entirely in its own process address space, on the same system as the applications that are using it. DCS communicates with the host container applications via IPC (InterProcess Communication); the protocol of the IPC is the OLE2 protocol. DCS has CTIClient embedded as an in-process (that is, a DLL) server, which in turn talks over a TCP/IP socket to the Cisco CTI Server.

By embedding CTIClient, DCS automatically provides insulation from the details of TCP/IP communications and the fault tolerance model employed by the CTI Server. DCS provides a layer of abstraction above CTIClient that adds state management and hides the complexity of the Computer-Supported Telecommunications Applications (CSTA) implementation. In addition, since the DCS is a local server, it can service many applications on a single desktop simultaneously. You may have multiple applications running on a single desktop that all need to react to an incoming call. DCS works across process boundaries to provide call information to all interested applications.

It is most likely that you will use DCS in conjunction with Softphone Controls—writing directly to DCS if your application requires functionality not included in the Softphone Controls. However, you can, if you prefer, use only DCS, ignoring the Softphone Controls.

Using DCS has several advantages over using CTIClient directly:

•DCS (an .EXE) runs within its own process address space; that is, it is an out-of-process server. While this does incur a slight performance penalty over a DLL, it also brings greater flexibility. With the Softphone Controls and DCS, you can just drag-and-drop to create a working soft phone. With CTIClient, you must code the application to embed CTIClient.

•DCS provides a greater level of abstraction than CTIClient. It is for this reason that the Softphone Controls talk to DCS instead of CTIClient. It is easier to drop the Softphone Controls into an application and start running immediately than it is to write an application that writes to the exposed methods of CTIClient.

•DCS allows Softphone Controls to use COMMonitor to provide fault tolerance. This provides a significant advantage in the area of fault tolerance at the desktop.

•DCS is designed to function as a one-to-many server. That is, a single instance of DCS can handle several client applications (running against the same teleset) simultaneously. This means one socket connection to the CTI Server instead of one for every client application, as would be the case with CTIClient embedded within multiple clients.

For more information on DCS, see the Cisco ICM Software Desktop Control Server Reference Guide.

Softphone Controls and CTI Desktop Softphone

The Softphone Controls are in-process (DLL) ActiveX objects that run in the host container application's process address space. The Softphone Controls communicate with the Desktop Control Server and the host container applications via IPC (InterProcess Communication); the protocol of the IPC is the OLE2 protocol. The Desktop Control Server has CTIClient embedded as an in-process server, which in turn talks over a TCP/IP socket to the CTI Server.

You can embed the Softphone Controls in any or all desktop host container applications in which you want CTI capabilities. The controls work through the Desktop Control Server (DCS) but operate independently of each other, so you may choose to use one or many of them. You can embed multiple instances of a given control in more than one application or in more than one place within an application. This permits you to put the functionality you need where you need it. The one-to-many configuration between DCS and all desktop applications is efficient because there is only one connection back to CTI Server. Additionally, all connected applications gain the desktop fault tolerance provided by COMMonitor.

Figure 4-2 CTI Desktop

Each Softphone Control contains both of the following public interfaces that your program can work with:

•An incoming interface that contains data properties you can set to establish initial values for agent or button attributes, and methods that your application can invoke to obtain agent attributes. For example, you can define the appearance—such as color and text—of a hold button by setting the appropriate properties in the Hold/Retrieve control.

•One or more outgoing interfaces that contain methods that the control invokes automatically when a relevant event occurs. For example, the Call Appearance Manager control outgoing interface invokes an OnSetCurrentCallAppearance() method when a different call becomes the current call.

CTI Desktop Softphone

CTI Desktop Softphone is basically a packaging of the Softphone Controls within a Visual Basic container application. However, CTI Desktop Softphone does contain additional code and graphics that provide some added value beyond the standard Softphone Controls on their own.

Since flexibility is the a cornerstone of the Cisco CTI model, the code for the CTI Desktop Softphone is provided free as part of CTI Desktop. You may use CTI Desktop Softphone as is, or to modify it to suit your particular needs. There is no copyright on the application, so you have complete flexibility to modify it as you choose.

AgentStatistics

AgentStatistics displays a real-time feed of agent statistics at the desktop, providing agents with information useful for self-evaluation and motivation. Because it is an ActiveX control, this functionality can run within the context of any ActiveX host, such as Visual Basic, Excel or a Web browser. Based on customer requirements, it can reside in the same host application as the soft phone or can execute and reside outside the soft phone. By default, the AgentStatistics control is contained within CTI Desktop Softphone.

SkillGroupStatistics

SkillGroupStatistics displays a real-time feed of skill group statistics at the desktop. In use and applicability it parallels AgentStatistics.

Flexibility of Softphone Controls

Most applications on the market are monolithic; that is, each is a single executable program that runs within its own process address space. This model is limiting because it inextricably combines the function of a program with its look and feel. What the Softphone Controls do is separate function (for example, put this call on hold) from presentation (that is, the look and feel of a soft phone) and where a particular function resides (that is, from which program an end-user is permitted to perform a given function). Further, Softphone Controls are largely indifferent as to the containing application, as long as it is ActiveX-compliant. So, for example, Softphone Controls are equally as at home within Microsoft Word or Excel as they are within a Visual Basic application.

Two examples will help illustrate this point.

1. A call center manager of a large bank wants the agents to have a soft phone on their desktop. Rather than have Cisco predetermine what the look and feel of the soft phone should be, the Softphone Controls permit the call center manager the flexibility to easily tailor the look and feel of the soft phone to meet the bank's particular needs. The call center manager can choose:

–The set of Softphone Controls to provide on the soft phone

–The text and language to be used on the buttons (particularly useful on agent function buttons)

–The dimensions and colors of the buttons and the containing soft phone

2. A call center manager determines that it is undesirable for the agents to have a separate application that performs soft phone functions. It would be better for the agents to have a single banking application on their desktop with all agent functions (business and telephony) performed from within that single application. This is frequently the case because, by limiting the agent's desktop to a single application, training costs are reduced.

A monolithic application makes this operating model impossible. Agents would be forced to toggle back and forth between banking application and soft phone. However, because the Softphone Controls are indifferent to the containing application, they can readily be embedded into the existing banking application (only provided that it can act as an ActiveX container). Therefore, from the agent's perspective, there is no difference between performing banking or telephony operations. Better still, the banking application itself is allowed to remain ignorant of the details of how the Softphone Controls perform their telephony functions. To the banking application, they are a black box. Not only is the call center manager able to get the environment desired, but the integration to the banking application is made significantly easier.

For more information on Softphone Controls, CTI Desktop Softphone, AgentStatistics, and SkillGroupStatistics, see the Cisco ICM Software Softphone Controls Reference Guide.

COMMonitor

CTI Desktop provides fault tolerance at the agent desktop level through a process called the COMMonitor. The COMMonitor runs automatically in its own process address space; it continuously monitors the availability of DCS components. In the event of a fault, COMMonitor automatically acts to restore the CTI connections. Client applications that use Softphone Controls do not need to do anything to respond to the failure; COMMonitor handles recovery automatically and without loss of application data.

JavaClient

JavaClient can be embedded into any Java host application or applet. JavaClient provides desktop applications with access to CTI Server functionality while abstracting the underlying details of the telephony system. As a result, CTI operations can be easily generated and integrated with business applications.

Figure 4-3 JavaClient

---

Note Like CTI Desktop, JavaClient currently requires that a client application be a desktop application handling a single teleset. It cannot be a CTI Bridge application.

---

Currently, CTI Desktop is more feature rich than JavaClient. However, you might prefer JavaClient over CTI Desktop because:

•Your agents do not have a Windows desktop. Rather, they might have UNIX, OS/2 or Mac at the desktop.

•You prefer to use a browser that either does not support ActiveX components or does not provide robust support for them. A popular example of the latter is the Netscape browser. Netscape does not provide native support for ActiveX components. Plug-ins are available (from a third-party vendor) that provide support for ActiveX. However, the ActiveX support provided by such plug-ins is generally not as full-featured as that provided by the Microsoft Internet Explorer browser.

•You want to use software written in Java.

For more information on JavaClient, see the Cisco ICM Software JavaClient Reference Guide.

Cisco Turnkey CTI

Cisco Turnkey CTI is a client-server application providing out-of-the-box CTI functionality for Cisco ICM/CTI. This application includes Cisco Turnkey CTI Server, an all events client of Cisco CTI Server. Cisco Turnkey CTI Server processes may be installed on a Peripheral Gateway co-resident with Cisco CTI Server, or may reside on a dedicated hardware platform. Also included is Cisco Turnkey CTI Agent, a desktop-installed, thick client to Turnkey CTI Server. Turnkey CTI Agent provides out-of-the box functionality at the desktop, including:

•Softphone toolbar, providing full third-party call control and agent state control (switch specific)

•Customer-defined workflow automation via task buttons

•Screen pops generated by telephony events that execute using keystroke macros

•Agent-to-agent text chat during conference calls

•Agent-to-supervisor text chat

The key advantage of Turnkey CTI is its ability to be deployed rapidly, realizing the benefits of CTI more quickly and with smaller requirements for professional services or customization. The trade-off for rapid deployment is less flexibility in the CTI application.

The Cisco Turnkey CTI solution is ideal for customers who:

•Utilize a Windows desktop that is not browser based

•Want to spend minimal effort and elapsed time on CTI services deployment

•Want to avoid exposure to the uncertainties of custom CTI development

•Desire the ability to configure, but not customize, the soft phone

•Require screen pop or other desktop workflow automation

Refer to the Cisco Turnkey CTI documentation for more information.