Computer Telephony Integration

This section of our technical library presents information and documentation relating to CTI Computer Telephony Integration software and products. Computer Telephony Integration CTI software is a rich set of phone software library routines that enable application programs to control your phone system. This comprehensive CTI software lets you increase employee productivity, enhance customer service and reduce costs by combining the capabilities of our PACER phone system with the custom functionality of your Windows, Unix or Web applications. Data collected by your phone ACD (Automatic Call Distribution) or IVR (Interactive Voice Response) systems can be passed to your existing PC, Unix or Web applications through our phone software. The PACER predictive dialer can automatically call your customers and pass only connected calls to your agents. With our computer telephony software, your telephone and computer work together to provide cost-saving benefits.

Sheng-Lin Chou, Industrial Technology Research Institute
Yi-Bing Lin, National Chiao Tung University

Abstract

• ITU/JTC1 specified Telecommunication Application for Switches and Computers (TASC) at the WP 4/14 (an ITU-T SG11 working group responsible for IN) in 1994. The specifications include a TASC general overview, architecture, functional services and management (architecture, methodology and requirements). An excellent overview for TASC is given in [9]. References for TASC are given later.
• ANSI/T1S1 specified the SCAI standard for PBX and Centrex in 1995.
• TTC (Telecommunications Technology Committee) of Japan specified the TTC PBX computer application interface in 1994 [10]. This specification is in line with the SCAI.
• ECMA has overseen the CSTA standard since 1988. This standard specifies the operation of switch and computing environments.
• ECTF specified SCSA in 1993. SCSA specifications apply to voice, fax and data processing boards for PCs.
• Intel and Microsoft developed TAPI specifications for the CTI application programming interface in 1993.
• Novell and Lucent initiated TSAPI development in 1993.

CTI Functions

CTI was developed to utilize computer intelligence to manage telephone calls. For example, CTI provides a better user interface compared with the traditional telephone interfaces that merely offer limited access methods through keypads. Furthermore, CTI provides platforms and functions that allow quick deployment for flexible telephone services. The CTI functions can be classified into three categories: call control, media processing, and customer data management.

Call control functions include:

• Call setup and release-related services such as dialing services and screening services.
• Routing-related services such as automatic attendant services and alternative routing services.
• Network interfacing services such as tone detection/generation, call setup/release detection, and in-band signaling detection.

• Voice/fax processing such as voice recording/announcement, voice and fax sending, broadcasting, storing and forwarding.
• DTMF (dual tone multi-frequency) digit processing, text-to-speech synthesis and speech recognition (such as spoken command recognition, speaker verification, voice cut-through and word spotting).
• Call logging such as on-line recording/monitoring and call accounting.

CTI Components

The CTI architecture consists of three components: the switch-to-host interface, the application programming interface (API) and the CTI resource architecture. The switch-to-host interface provides connection between the switch and the host (the CTI server). The API allows a software developer to create new functions/services for the CTI system. The CTI resource architecture manages the telephony and computing resources such as speech recognition and fax boards.

Switch-to-Host Interface

The switch-to-host interface provides connection between the switch and the host computer (a CTI server). Most traditional switches are closed systems that do not provide an interface for external control. In computer telephony applications, the switch is required to be controlled by the CTI server running the applications. This kind of interface is called the CTI link, which is different from a phone line interface. To support external control, many switch vendors offer proprietary interfaces such as Lucent's Definity G3 [11] and Nortel's Meridian Link [12]. Being connected to a switch via CTI link, the CTI server presents the telephony environment to the application programmers with standard APIs such as TAPI and TSAPI, discussed later.

Two technologies have been proposed for the CTI link interface: Computer Supported Telecommunication Applications (CSTA) [3, 13] and Switch to Computer Application Interface (SCAI) [14]. The development of CSTA was initiated by the European Computer Manufacturers Association (ECMA). SCAI is an ANSI version of a CSTA-like interface but is much more complicated, similar to an IN system. Institute SCAI applications include simultaneous transmission of voice and data, call re-dialing, and computer supported call dialing and transfer.

Recently, most PBX vendors have adopted CSTA as the industry standard. CSTA is the base on which TSAPI is defined. Almost every CSTA service has a one-to-one correspondence to a TSAPI function call. CSTA consists of the CSTA services and the CSTA protocol. The CSTA protocol specifies the command sets and the data structures for communication between the switch and the host. Through this protocol, the host accesses the CSTA telephony services from the switch or provides the CSTA computing services to the switch. In specifying the services, CSTA defines a telephony process model for the host computer and a computing process model for the switch. Each of the models consists of a set of objects, the states in which an object can exist, and the rules for state transitions. Examples of telephony objects include device, connection, and call. A device object can be either a physical device (such as a button, line, trunk, and station) or a logical device (such as a group of devices, pilot number, and automatic call distribution (ACD) group). A device has attributes, including device type, device profile, device identifier, and device state, that are allowed to be monitored and manipulated by the computing function. For example, a device object representing a telephone has an attribute "identifier" (directory number) and operations such as "monitor."

• A call object describes the logical session among the calling and called parties. The call behavior, including establishment and release, can be observed and manipulated by computing function. A call object representing a call session has attributes such as "identifier" and "state," and operations such as "make" or "clear." One or more devices may be involved in a call at different stages. One device in a call may be replaced with another device as the call is transferred, and two calls will be merged into a single call as the conference operation is issued.
• A connection object represents a relationship between a call and a device, which has attributes such as "identifier" and "state," and operations such as "hold" or "clear." Many CSTA services, such as hold-call, reconnect-call, and clear-call, are made by operating on connections comprising a call. A connection is mainly characterized by connection states, which may be reported on either calls or devices, and changes in connection states may be reported as event reports.

• Application program with attributes "identifier" and "state," and operations such as "execute."
• File directory with attribute "identifier" and operations such as "search."
• File with attribute "unique ID" and operations such as "open" or "read."
• Database record with attributes "static ID" and "dynamic ID," and operations such as "read" or "write."

Application Programming Interface

The application programming interface (API) is an interface that enables software developers to create new telecommunication applications. This section describes three API standards: TAPI, TSAPI and JTAPI.

TAPI and TSAPI -- Microsoft's Telephony Applications Programming Interface (TAPI) [15], developed for Windows-based PCs, enables programmers to implement telephony applications. An early version of TAPI (TAPI 1.3) was released in November 1993. This version was designed for the first-party call control configuration (to be discussed later) running on a 16-bit processor. An enhanced version TAPI 1.4 was released as part of Window 95. These versions do not support a call model such as the one defined in ITU-T Q.931 [16]. TAPI enables a speech/data application to set up and tear down calls, monitor progress, detect CLID (calling line identification), perform identification, and activate features such as hold, transfer, conference, park and pickup. It can redirect and forward calls, answer and route incoming calls, and generate and detect DTMF signals. TAPI enables multiple applications to share a single phone line. For example, different types of incoming calls (e.g., voice mail and fax) can be accepted on the same line. Enabling these devices to share a single telephone line allows the user to make more efficient use of the line. TAPI provides access to various telephone network services:

• Plain old telephone service, which supports one type of information (voice or data) per call and one channel per line
• ISDN, which supports simultaneous voice/data per call and multiple channels per line
• Digital network services, which support data communications
• Other services such as Centrex, PBX and KTS (key telephone system)

JTAPI

The Java Telephony API (JTAPI) [21] provides a portable, object-oriented API application programming interface for Java-based computer-telephony applications. It supports both first-party call control and third-party call control to implement telephony applications such as desktop, Web-page, and distributed call center applications. JTAPI runs on a variety of system configurations, including centralized servers with direct access to telephony resources, and remote network computers with access to telephony resources over a network. Figure 2 illustrates the JTAPI network configuration, where the JTAPI application or Java applet (Fig. 2 (1)) runs on the JAVA run-time environment (Fig. 2 (3)) at a remote computer. A JTAPI client communicates with the centralized server (Fig. 2 (5)) that manages telephony resources via a remote communication mechanism, such as Java's RMI (Remote Method Invocation) [22], JOE (an ASCII-text screen editor) [23], or a telephony protocol (Fig. 2 (4)). The implementation of the remote telephony server can be based on existing TSAPI or TAPI systems (Fig. 2 (6)). The JTAPI interfaces (Fig. 2 (2)) are grouped into building-block packages including the core package and several extension packages. The core package provides the basic framework to model telephone calls and rudimentary telephony features, which include placing, answering, and disconnecting telephone calls. Each of the extension packages brings additional telephony functionality to the API. The extension packages defined in JTAPI 1.2 include call control, call center, media, phone, private data, and capabilities packages. In addition to the core package, the JTAPI package architecture allows telephony server implementations to choose appropriate extension packages developed based upon the capabilities of the underlying hardware. On the other hand, applications choose the extension packages and the core package to accomplish the desired tasks.

CTI Resource Architecture

Within a CTI system, one or more kinds of hardware resources are required to implement the CT-enabled functions. These resources include analog/digital trunk interface boards, voice processing boards, fax boards, the speech synthesis/recognition boards, and so on. A CTI resource architecture is typically an open system that supports interoperability among various CTI resources made by different vendors. Standards for the CTI resource architecture [7] include Multivendor Integration Protocol (MVIP), Signaling Computing System Architecture (SCSA), and ECTF H.100/H.110.

MVIP -- MVIP (Multivendor Integration Protocol) [24] is a family of open standards that support integration of voice processing, fax/data protocol communications, and other computer technologies that require connection to the telephone network. In other words, MVIP offers a standard approach to integrate PC technology with proprietary PBXs and other telephone switching systems. MVIP-90 is the original MVIP standard that specifies a time-division multiplexing (TDM) bus with 512 x 64 kb/s capacity and the distributed circuit-switching capability inside the computer under software control. H-MVIP (high capacity MVIP) is a compatible superset of MVIP-90, which extends the system to handle up to 3072 x 64 kb/s. In addition to the switching capability, the MVIP specification also includes a common device driver interface that is transparent to application programmers, regardless of who manufactured the hardware resource boards. Both MVIP and H-MVIP are defined on a single-chassis environment. A family of multi-chassis MVIP (MC-MVIP) standards has been defined to scale MVIP systems to any size. These standards use common software and several alternative physical means to provide two to several thousand 64 kb/s channels (time-slots) between MVIP and other telephony-equipped chassis.

SCSA -- SCSA (Signaling Computing System Architecture) [25, 26] is a comprehensive, open architecture for integrating computer telephony resources. It contains not only the hardware model that specifies the CTI bus for real-time data switching but also the software model that identifies the services for media processing and call control. The SCSA software model is called Telephony Application Objects (TAO) Framework, which objects identify a set of interfaces and services for manipulating the media of a call (play, record, speech-recognition, and so on) and for accessing the appropriate call control elements. In addition to the interfaces and services, the SCSA TAO framework also defines a standard message interface to ensure the flexibility and vendor independence at the hardware level. This software model assumes that there is a switch fabric for connecting the physical call processing resources together. The SCSA hardware model characterized by SCbus identifies the interfaces and protocols for implementing a flexible, high-capacity, TDM switching bus. The hardware model makes it easy to distribute resources among various servers through a multinode connector known as the SCxbus. The SCbus is a flexible, high-capacity TDM switching bus within a CTI server. It supports 1024 and 2048 TDM switching time slots for ISA and VME-bus systems, respectively. To expand the scale of a SCSA system, multi CTI servers can be connected via SCxbus so that the resources among the servers can switch the information through the same TDM bus.

ECTF H.100/H.110 -- ECTF (Enterprise Computer Telephony Forum ) specifies a high-capacity bus, called H.100 CTI Bus [27] to provide compatibility modes for existing products. As such, the new CTI Bus has been deemed the industry's solution to "end" the bus wars. The features of the H.100 CTI Bus include [28]:

• Increased capacity: 4096 time slots running at 8 MHz (vs. 2048 for SCbus and 512 for MVIP-90).
• Redundancy: dual clock and frame synchronization lines so that if one clock line is lost, all devices can be synchronized with the other clock signal.
• Interoperability: 16 of the 32 data lines can be selectively downgraded to 2 MHz for MVIP-90 or 4 MHz for certain SCbus modes. H.100 also supports telephony bus-specific features, such as an optional message channel.

• Running the CT Bus on the backplane rather than on a ribbon cable
• Hot swapping of cPCI cards and a form factor that is acceptable to a wider audience, including telcos

CTI Configurations

This section describes two CTI configurations: the first-party call control configuration and the third-party call control configuration. In the first-party configuration, a call is controlled by the call parties. On the other hand, in the third-party configuration, a call is initiated from a device that does not participate in the call. In other words, a third-party call is one in which a "big brother" can affect the state of the call without participating in the media session. In both the first-party and the third-party call control configurations, the voice/data information is delivered through the telephone links/trunks.

First-Party Call Control

First-party or phone-oriented call control is a direct interface between the user's personal computer and the telephone switch, which intercepts line signaling between the telephone and the switch and is thus provided on a single-line basis. Basic first-party call control limits itself to the conventional signaling conditions used in PSTN-compatible telephones. Enhanced first-party call control accommodates signaling for proprietary feature phones. TAPI is the industry's primary example of first-party call control API.

Figure 3 illustrates the first-party call control configuration. In this configuration, the switch (Fig. 3 (1)) can be a standard one, which is not aware of the connection of the first-party configuration.

The computer (Fig. 3 (2)) can be a typical PC with call control software. The telephone functions do not all work if the PC power is turned off.

Conventional phones with standard signaling capability (Fig. 3 (3)) are used for the basic first-party configuration. For the enhanced first-party configuration, key telephones with proprietary signaling are required.

The telephone-computer interface is usually a phone line connection in a first-party call control system. This connection can be via RJ-11 phone jack, RS232 or Universal Serial Bus (USB) [30]. USB is an expansion scheme that replaces the serial cards in a PC. USB enables CTI by providing a high-speed serial connection to the PC's bus. As many as 63 devices can be connected to the same bus. The telephone line control protocol for setup and release can be the Hayes command set [31] used for modem auto-dialing. The telephone can be a board plugged into an expansion slot of the PC, or the telephone can plug into a jack in an expansion card.

The first-party call control configuration is ideal for small offices. This configuration is independent of the telephone type, and can interface analog, ISDN, or proprietary digital telephone ports in a switch.

Third-Party Call Control

The third-party or switch-oriented call control system controls the switch through a separate X.25 connection using a CTI link protocol. The CTI link protocol can be CSTA. An example of the third-party call control API is TSAPI. The TSAPI-enabled application program is viewed as an external agent (the third party) in a conversation between the calling and the called parties. The third-party call control configuration is illustrated in Fig. 4. This architecture follows the client-server approach where a CTI server (Fig. 4 (1)) extends telephone functionality to the PC-based clients (Fig. 4 (2)) through a LAN (Fig. 4 (3)). A computer client may send a request message to the switch to answer a call, hold a call, or make a new call (Fig. 4 (4)). The switch acknowledges the request, possibly processes the request, and returns a status message. Similarly, the switch may send a PC a request message to run a program or to access data (e.g., to obtain routing information for a particular call). In this configuration, the CTI server and the switch (especially for small-scale switches such as PBX) can be combined into one component. This modified configuration (Fig. 5) renders a programmable switch via the server, resulting in flexible call control and media access functions for the clients. We will describe a CTI system based on this configuration.

Compared with first-party call control, third-party call control is more adaptable to large sites because it is not necessary to buy hardware and software for each desktop. In first-party call, the interaction between the computing function (CT server) and PBX is limited by the in-band signaling capability and the Hayes command set. On the other hand, in third-party call control, the signaling and control between CT server and PBX is through out-band channel. The CT application in the CT server can get almost all needed events on telephony objects and then control the operations of the objects. Since an out-band channel and a signaling protocol are required for third-party call control, only the third-party call control will be cost-effective for large applications.

Features and Applications

CTI applications are achieved by handshaking between computer and switch. To enhance this interaction, several features have been intensively utilized in CTI applications. This section describes CTI features such as interactive voice response and screen pop, and applications such as a unified messaging system and call center.

Interactive Voice Response (IVR) -- The user accesses the IVR system through the telephone set. The system interprets the user's command to the computer, and the computation results are converted to voice. IVR is typically used in transaction-based (database) applications such as train ticket reservation systems and account information query systems. IVR also provides voice services such as audio-text (for pre-recorded voice message).

Screen Pop -- Screen synchronization or screen pop delivers a call to an agent (telephone operator) together with the customer's account screen. That is, during ringing, the caller information is displayed to the called party (the agent) through an ADSI (Analog Display Services Interface) phone or a GUI-based phone. Screen pop is enabled by identifying the caller from the calling telephone number (caller ID), or from a customer-dialed personal identification number (PIN) that is captured in an IVR or call prompter. When a call is transferred to another agent, the information on the original agent's screen is automatically sent to the receiving agent. This feature is called call/data association.

Unified Messaging System (UMS) -- The UMS server integrates a commercial e-mail server with voice and fax mail servers to provide a unified mailbox that can receive messages of various kinds. UMS supports several user interfaces such as a telephone user interface, a graphic user interface and Web interface. The users utilize these interfaces to access e-mail, voice and fax messages. For example, a person in a foreign country may need to dial up back to their home country to access their voice mail. With UMS, this person can access the Internet to retrieve UMS messages through a Web browser. Furthermore, a UMS user can send voice mail via an e-mail mechanism and fax electronic data files using a GUI or Web interface. The electronic data files can be of Microsoft Word, Powerpoint or other formats.

Call Center -- This application is considered a killer CTI application, and is typically used in telemarketing, debt collection and help desk. CTI-based call center supports automatic call distribution (ACD) with features such as call distribution, call queueing, on-hold announcement, and other phone functions such as call transferring/conferencing. The ACD connects to a CTI server through the CTI Link. Figure 6 shows the CTI call center architecture. In this architecture, any call to the system is forwarded to the ACD (Fig. 6 (1)). Before the ACD distributes the call, the IVR may interact with the caller to pre-process the call, e.g., to request a PIN number or to provide voice-based services (Fig. 6 (2)). The help-desk application retrieves the customer's record from a database (Fig. 6 (3)). The database may consist of the customer's profile and service support systems for billing, telebanking, and so on. The ACD distributes the call to an available agent (Fig. 6 (4)). An agent is typically equipped with a headset, desktop computer and the service guide script. With the screen pop feature, the customer's data is shown on the screen of the agent (Fig. 6 (5)) as the phone rings. If the call is transferred to another agent, the customer's record is also transfered to the new agent's screen.

IOTS: An Example of a CTI System

A CTI system called Integrated Office Telephony System (IOTS) [32, 33], developed at Computer Communication Research Laboratories, has been successfully commercialized for supporting call center services. IOTS integrates both PBX/ACD and CTI server functions in an NT-based PC. In other words, IOTS follows the integrated server/switch configuration illustrated in Fig. 5. Figure 7 shows the functional architecture of IOTS, which is a client-server CTI system supporting both TAPI 2.0 and TSAPI. The IOTS server (Fig. 7 (1); see also Fig. 5 (1)) is equipped with SCSA-based analog or digital trunk interface boards (Fig. 7 (2)) connecting to central offices in the PSTN (Fig. 7 (3); see also Fig. 5 (2)). The station boards ((4), Fig. 7) interface with internal phone stations (Fig. 7 (5); see also Fig. 5 (3)). With the SCbus switching capability (Fig. 7 (6)), the CSTA-based PBX switching platform is constructed and the ACD module (Fig. 7 (14)) is implemented on the CSTA switching platform. The TSAPI server processes the TSAPI calls from clients by using the CSTA PBX services. At the client side (Fig. 7 (7); see also Fig. 5 (4)), TSAPI DLL (TSAPI dynamic link library; see (8), Fig. 7) is used to support the TSAPI function calls (Fig. 7 (9)) and link them to the TSAPI server (Fig. 7 (10)). The communication between clients and server is achieved by WinSock [34] (Fig. 7 (11); see also Fig. 5 (5)) which supports socket programming for the Microsoft Windows environment. The IOTS_TAPI.TSP (Telephony Service Provider) module (Fig. 7 (12)) is implemented at client sites according to TSPI (Telephony Service Provider Interface) specifications defined in Microsoft TAPI 2.0. For a TAPI call, the IOTS_TAPI.TSP drives the CSTA PBX services through the mediation of the TAPI server (Fig. 7 (13)). An IOTS application can register to the IOTS system for monitoring call events and take over the call processing control. During call processing, the application may access the database to integrate a call with corresponding data. Many CTI features (such as screen pop, call-base data selection, call/data association and intelligent call routing) can thus be easily achieved. In the remainder of this section, we describe two IOTS applications.

Intelligent Office Telephony System

Based on TAPI and TSAPI interfaces, IOTS supports advanced telephony functions for an office environment. Since it is awkward to access rich telephone functions via simple keypads, IOTS provides a friendly graphical user interface (GUI) for phone function access. Figure 8 shows the appearance of the GUI phone on the user's screen. In addition to the call control functions such as call transfer, consultation, and conferencing, the IOTS Phone can be integrated with personal information such as a phone-book and schedule. When the user presses the dial button, a name list is shown on the screen to offer the dial-by-name service. The same scenario applies to call transfer and call conferencing. With an IOTS phone, users can dynamically set the call routing destinations according to their daily schedules. For example, one may set the incoming calls to the phone on the office desk during working hours (8:00-17:00), to the cellular phone from 17:00 to 20:00, and to the voice mail box for the rest of the day. An IOTS phone user can also record the conversation by pressing a specific button on the screen. The above office telephony features are achieved by combining the computer's intelligence, data management capability and IOTS's programmable PBX services.

Call Center Application

Integrating an IVR application with a legacy ACD system is not trivial for a traditional call center system. On the other hand, the IOTS architecture conveniently integrates IVR with the ACD module to provide flexible CTI call center services. IOTS provides ACD functions, campaign management,2 agent management, traffic management, on-line monitoring, and statistics/reporting capabilities. An IOTS IVR application was developed using TSAPI to support various voice services, including audio-text, fax-on-demand, and billing record query. When a call arrives, the IVR first asks the caller (customer) to provide his/her PIN number. IOTS uses this number to access the customer's profile stored in the database, and then provides the voice services. To connect a customer to an agent, the IVR application returns call control to IOTS/ACD with a message indicating the campaign (group) of the call and the information about how to distribute the call. For example, if the caller is a VIP, then the call may be processed by a dedicated agent with high priority.

When a call is distributed to an agent, the call center application at the agent site is notified about the arrival of the call and is able to access the customer's profile from the database. Therefore, when the agent's phone is ringing, the customer's profile is immediately shown on the agent's screen using the screen pop feature. Figure 9 illustrates an example of the customer's profile. This profile consists of a customer's picture, customer information (such as ID, name, address, phone number and fax number) and other information such as accounting statistics.

The agents use the GUI phone described previously to conveniently control the phone's functions. Furthermore, the GUI phone supports agent functions such as log-in, log-out, not-available, wrap-up, and so on.

The following example illustrates how an IOTS call center handles a billing account query issued by a credit card holder.

• The card holder (Fig. 7 (3)) makes a call to the IOTS call center at the card company. The customer call is first served by the IVR system and then is transferred to the CTI server (Fig. 7 (1)) as the customer presses some digits and attempts to talk with a live agent. The customer ID and any information (e.g., IVR-profile) collected by the IVR system will follow the call and be carried to the CTI server.
• The CTI server examines the IVR-profile of the call request and checks the customer profile stored in the customer database. The CTI server decides how and where to distribute the call by checking the agents available information. For example, for an VIP customer, it should not be queued for too much time or it should be handled by a dedicated agent (Fig. 7 (7); the call setup process may involve (10) and (8) for TSAPI or (13) and (12) for TAPI). The CTI server may also select an appropriate agent to which the call request should be routed according to the service type requested. The call can even be routed to the same agent in case the customer just hung up a previous call several minutes ago.
• If all agents are busy, the CTI server passes the call to the ACD (Fig. 7 (14)) and the call is put to a proper queue. If the call is assigned to an available agent, the ACD notifies the CTI server. As it is being notified, the CTI server then passes the customer profile and request service data to the agent's desktop so the customer data can appear on the agent's screen (e.g., the screen illustrated in Fig. 9) as it receives the call.
• During the agent service period, the agent may request another agent (e.g., the supervisor) to join the call conference or just transfer the call to the new agent. In this case, the customer's data will appear on the new agent's screen at the same time.
• As the customer hangs up the call, the CTI server then updates the service information in the database and decides when to call back the customer for follow-up if necessary.

Remarks and Further Reading

Computer Telephony Integration (CTI) is a technology that utilizes computer intelligence for telecommunication services. This article provided a tutorial about CTI. We first introduced CTI components including the application programming interface, CTI resource architecture, and switch-to-host interface. Then we described two CTI configurations: the first-party call control configuration and the third-party call control configuration. Some CTI features (interactive voice response and screen pop) and CTI based telecommunication services such as unified messaging and call center were described. To show how CTI concepts can be applied in a telecommunication product, we illustrated IOTS, a CTI system that integrates the PBX and CTI server on a personal computer platform.

From the discussions in this article, several evolving trends related to CTI are observed. First, CTI will be based on a client/server model, where the phone will become part of the PC in CTI and the PBX will become part of the server on the LAN in CTI. Our experience indicates that the NT platform will dominate CTI server systems. Second, CTI will utilize the Internet as the backbone. In Internet telephony [35], both signaling messages and real-time voice conversations are delivered through the Internet. In the future, CTI and Internet telephony will be tightly integrated. Specifically, CTI will become a natural adjunct to Internet telephony.

Several issues are still open for CTI, including security and reliability. If CTI techniques are utilized for CPE, then these issues are not a major concern. On the other hand, for PSTN applications, security and reliability must be effectively addressed. More information about CTI can be found in [36­39], and [40]. For information about CTI products, the reader is referred to [41­43] and the references therein. For CTI standards [9], the reader is referred to ITU-T Recommendations Q.1300 [44], Q.1301 [45], Q.1303 [46], ECMA Specifications 179, 180, 217, 218, 269 [47], ECTF Specifications A.001, A.100, C.00, S.110, S.200, S.300, S.400, S.900, H.300 [48], and ATM Forum [49] VTOA Specifications af-vtoa-0078.000 [50], af-vtoa-0083.000 [51], af-vtoa-0085.000 [52], af-vtoa-0089.000 [53].

Acknowledgment