Computer Telephony Interface (CTI) Devices

This section describes CallManager's application interface implementation and the underlying CTI. CTI is the internal interface to CallManager, on which the standard interfaces, such as TAPI and JTAPI, are supported. CTI communication from the application platform to CallManager is through TCP/IP.

CTI Application Architecture Overview

The CTI application architecture provides a means of controlling call behavior from external applications. CallManager provides already developed applications and a development infrastructure to allow third-party application development.

Figure 3-14 shows the CallManager infrastructure that supports the applications. The applications run on the application platform and make use of the application services. Applications provide a high-level functionality that is usually specific to a particular need, such as IP Contact Center, voice messaging/unified messaging, and so on. The applications might have media termination functionality or might simply control stations that actually terminate the media. The application platform and services provide the application programming interface (API), call control protocols, administration and serviceability functionality, and directory and database interfaces.

Figure 3-14. CallManager Application Infrastructure

 

Application Layers External to CallManager

Application layers that are external to CallManager allow an application to interface to CallManager. The two primary application service APIs supported by CallManager are TAPI and JTAPI. These two APIs enable developers to extend the capabilities of CallManager to meet specific enterprise needs. The choice of TAPI or JTAPI is based on the particular needs and preferences of your organization.

The Cisco architecture for both TAPI and JTAPI, shown in Figure 3-15, supports a redundant connection to CTIManager so that if one CTIManager is down, the application can still communicate with the other CTIManager and continue functioning.

Figure 3-15. Cisco CTIManager Redundancy

 

TAPI

Microsoft's TAPI for Windows was initially used for first-party device control for devices that were co-resident, such as controlling modems. The application would initiate a modem connection from the software running on the personal computer to a destination provided by the application. TAPI was extended to include a telephony server for third-party remote control, such as PBX devices. The TAPI framework abstracts the telephony services from the CallManager infrastructure. The applications are more portable and insulated from the effect of changes in new CallManager releases.

Figure 3-16 illustrates the components that make up the TAPI architecture and reside in the PC running the telephony application. The TAPI architecture is an abstraction layer between the TAPI applications and the underlying hardware and transport protocols of CallManager. The TAPI application accesses the device-specific controls for communications and call processing through a dynamic link library (DLL). Each TAPI application is a separate process that communicates using TAPI with Tapi32.dll or Tapi3.dll, provided by Microsoft. Tapi32.dll and Tapi3.dll communicate with the TAPISRV.EXE process using a private remote-procedure call (RPC) interface. TAPISRV.EXE is a Microsoft process that runs as a Windows service. TAPISRV.EXE communicates with the telephony service provider (TSP) using Telephony Service Provider Interface (TSPI). The Cisco TAPI Service Provider (Cisco TSP) is a DLL that runs under the TAPISRV.EXE process. The Cisco TSP communicates with CallManager through a TCP/IP interface known as CTIQBE. The Quick Buffer Encoding (QBE, pronounced "cube") format is based loosely on Microsoft's TAPI buffer format. QBE defines C-language structures that can be byte-copied directly to or from an input/output stream. The Cisco TSP allows developers to create customized IP telephony applications for CallManager.

Figure 3-16. Cisco TAPI Architecture

The Cisco TSP supports first-party call control or third-party call control. In first-party call control, the application terminates the audio stream. With third-party call control, the application controls the audio stream of some other audio stream-terminating device. The device can be a particular station or a group of stations for which the application is responsible. CallManager for TAPI currently supports 2.0 and 2.1.

CallManager supports many CTI-controlled/monitored devices and the number depends on the CallManager server size. Depending on the server size, CallManager can scale up to 2500 CTI devices per CallManager server, up to 2500 CTI devices per "provider," and up to 10,000 CTI devices per CallManager cluster.

JTAPI

JTAPI provides similar functionality for Java-based applications development. JTAPI supports call control and primitive media support. Compared to TAPI, JTAPI is more operating system independent. CallManager for JTAPI currently supports JTAPI 1.2.

CallManager supports many CTI-controlled/monitored devices and the number depends on the CallManager server size. Depending on the server size, CallManager can scale up to 2500 CTI devices per CallManager server, up to 2500 CTI devices per "provider," and up to 10,000 CTI devices per CallManager cluster.

See Appendix C for specific details of the following JTAPI packages:

• Core Package
• Call Center Package
• Call Center Capabilities Package
• Call Center Events Package
• Call Control Package
• Call Control Capabilities Package
• Call Control Events Package
• Capabilities Package
• Events Package
• Media Package
• Media Capabilities Package
• Media Events Package

CallManager also provides the following RTP Termination extensions:

• Special CallManager device types (CTI ports) can be registered by applications.
• Devices must be preprovisioned (no programmatic creation).
• Codec and RTP parameters are selected by CallManager during call setup.
• An application must implement an RTP stack, although Java Media Framework (JMF/JavaSound) is allowed for client applications.

CTI Layer

The CTI layer within CallManager provides a generic interface to the application layer. The CTI layer is the means by which the CallManager-specific capabilities of the application layer are implemented.

Figure 3-17 shows the CTI functionality within CallManager. CTI communicates with the application platforms through the TCP/IP layer to provide the CTI functionality of CallManager. The CTI layer is an integral part of CallManager.

Figure 3-17. CallManager CTI Functionality

CTI interacts with the other CallManager components through the Signal Distribution Layer described in Chapter 1, "Cisco CallManager Architecture." CTI works together with the station module to provide the signals from a CTI device. If a station device such as a Cisco IP Phone is being controlled by an application, CTI interacts with the station module in CallManager responsible for the particular station being controlled.

The application also needs information about activity at a selected station. CTI receives notification about station activity, known as events, from the station components for stations that the application is monitoring.

CTI also interacts with the supplementary services component to provide additional call control capabilities, such as transfer and conference. The CTI component can invoke supplementary services on behalf of stations being controlled or directly for CTI application devices. CTI also sends event notifications of supplementary service activity for selected stations being monitored by an application.