Figure 12-11 Windows telephony service provider in Software

Drawer QR Code in Software Figure 12-11 Windows telephony service provider

Macintosh Telephony Architecture (Telephone Manager): Telephone Tools The low-level portion of the Macintosh Telephony Architecture is based on the Telephone Manager The Telephone Manager defines the vendor-specific software components it uses to access CTI functionality as telephone tools In the Macintosh Telephony Architecture, telephone tools are coupled with a device handler and one or more media drivers This is illustrated in Figure 12-12 The device handler portion is responsible for handling the media streams associated with a given CTI service, and for ensuring that media access is shared and appropriately reflected by both the media drivers and the telephone tool The structure for the device handler is not defined by Apple12-7

12-6

Telephony Service Provider Interface The Telephony Service Provider Interface, or TSPI, is documented in the book Telephony Service Provider Programmer's Reference available from Microsoft through the Microsoft Developer Network Library

Java Telephony (JTAPI): JTAPI Providers The Java language is object oriented so the Java telephony API, JTAPI, is defined in terms of objects and the methods that can be used to operate on them However, this is not the only difference between JTAPI and the procedural interfaces discussed in this chapter JTAPI's objects are defined12-8 in terms of interfaces that must be implemented by a set of objects that constitute the CTI client software TAPI and the Telephone Manager are pieces of operating system software that actually act as the CTI client implementation They provide interfaces to adapter software (TSPs and tools) which is different from the interface that they expose to client applications In contrast, JTAPI represents a zero-thickness interface because the client application interfaces directly with the client implementation using the methods defined by JTAPI

12-7

Telephone Tool specifications Documentation for developing telephone tools is contained in the book Telephone Manager Developer's Guide that is part of the Mac OS Software Developer's Kit This product is available from Apple through APDA (Telephone Manager Developer's Guide, Apple Computer, Inc, 1991)

12-8

JTAPI specifications documentation for developing JTAPI peers is contained in the JTAPI documentation which is available from the Java web site at: javasuncom/products/jtapi/indexhtml

A JTAPI client implementation is encapsulated by an object known as a JtapiPeer When a JTAPI client application desires access to a particular logical CTI server, it instantiates the corresponding JtapiPeer object (using a JTAPIPeerFactory object) The JtapiPeer object is responsible for establishing communication with the logical CTI server and for instantiating a JtapiProvider object that, in turn, provides an application objects for interacting with calls, connection, devices and other resources in the switching domain Java software is designed to be run on any computer that provides a Java virtual machine Given the nature of Java, JTAPI was designed to be layered above popular procedural CTI APIs in addition to CTI protocols and local CTI server implementations as shown in Figure 1213

125 CTI Low-Level Application Programming Interfaces (APIs)

Programmatic interfaces for CTI fall into three categories: Implementation-specific Implementation-specific CTI interfaces are those in which a proprietary interface is defined and implemented as part of a particular CTI client implementation Operating-system-specific Operating-system-specific CTI interfaces are defined and implemented as part of an operating system implementation The two most popular personal computing operating systems, Mac OS and Windows, each have their own low-level APIs for CTI These are the Telephone Manager and TAPI respectively Platform-independent Platform-independent CTI interfaces are those that are designed to work with any platform JTAPI12-9 and TSAPI12-10 are the only platform-independent low-level CTI interfaces TSAPI is characterized as a very thin API layer that provides direct access to standard CTI protocols TSAPI's primary goal is ensuring that every piece of available information and every accessible capability of a given switching domain implementation is made available to client software, independent of operating system platform The specification of the TSAPI interface is focused strictly on accessing and using the CTI functionality represented by the standard CTI protocols It provides a layer above the raw protocol that simplifies software access by providing functionality for encoding and

12-9

JTAPI All references to JTAPI are to the versions and packages of JTAPI identified in the ECTF C 100 specification

12-10

TSAPI All references to TSAPI are to the definition of Versit TSAPI as specified in the Versit Computer Telephony Integration (CTI) Encyclopedia Earlier versions of TSAPI, including Novell's TSAPI implementation for the NetWare environment, are effectively subsets of Versit TSAPI

decoding and managing the queues of incoming and outgoing messages, without providing any interpretation of the protocol that might lead to loss of information or accuracy JTAPI is the Java language's standard API for CTI (and also for telephony media services as described in section 1261) Like TSAPI, it is based on the standard CTI protocols and is designed to support the full range of CTI functionality on any operating system where a Java virtual machine is running However, it is also similar to the OS-specific interfaces in that its design is optimized for a particular operating environment; the Java virtual machine in this case, and for use by programmers familiar with the conventions of standard Java APIs JTAPI was also designed so that it could be used with proprietary protocols by taking advantage of available adapter software written for a given OS-specific interface that it could be layered upon On the other hand, OS-specific interfaces were designed and developed with slightly different goals The principal focus of these APIs is to simplify the programming task for the majority of CTI application developers who are using the facilities of the operating system in question This has resulted in simplifications that may help most application developers, but also has reduced the information available for certain types of applications In other words, operating system interfaces attempt to provide an additional layer of functionality above the raw messages from the switching domain These extras include: Providing a simplified first-party call control model; Presenting distinct interface subsets for the three different aspects of CTI (call control, telephone control, media access); Tracking switching domain capabilities;

Tracking call identifiers on behalf of applications; Mapping switching domain identifiers into handles and local identifiers; Tracking state, status, and setting information on behalf of applications; Tracking what services are and are not applicable to a connection at a given instant; Tracking service completion on behalf of applications; Abstracting differences between digital data and voice calls; Supplying mechanisms for arbitration of call ownership between applications; and Integrating tightly with OS-specific media service APIs Of all these features, the first is the most significant distinction Existing operating-systemspecific interfaces (TAPI and the Telephone Manager) derive much of the simplification they offer to application developers by abstracting all switching domains as first-party (Refer to 6, section 652 for the definition of first-party call control) This simplification reflects the fact that most CTI applications are concerned only with a single device Depending on the service provider or telephone tool being used, support for logical CTI servers offering third-party call control is accomplished either by representing every device as a distinct switching domain, or by representing it as many devices that are part of a large device configuration In practice, either type of low-level API can be used for most applications, assuming that any needed functionality factored out by the OS-specific API still can be accessed through an escape mechanism in that API When developing a telephony-specific application, the

following trade-offs must be considered in choosing between using a platform-independent interface (TSAPI) or an OS-specific interface (TAPI and the Telephone Manager): First-party call control If an application only requires the ability to observe a single device or device configuration, either type of API may be used If an application needs the ability to track calls that travel between multiple devices, it probably will be easier to develop using TSAPI Application short cuts TAPI and the Telephone Manager provide interfaces in which much of the work associated with tracking information from the switching domain is handled automatically When the information is needed by an application, it is immediately available On the other hand, applications using TSAPI must themselves track all of the pertinent pieces of information that arrive in messages and might be needed later This includes tracking information to determine what service requests can be applied to a call given its state, and the presence of dynamic feature presentation information if provided Veracity TSAPI provides the most complete view of what is taking place in the switching domain While the functionality of the other APIs is quite good, they do involve many more simplifications (and hence mappings) than TSAPI, and ultimately they represent a subset of the full feature set that TSAPI has access to through standard CTI protocols Portability While implementations of TSAPI on different platforms must differ slightly to adapt to the way each operating system works, the main benefit of a platform-independent interface is to allow greater portability between platforms Telephony-specific software that is not otherwise using OS-specific

functionality (graphical user interface support, native file management, etc) can be ported between platforms with little or no effort Realistically speaking, however, most applications do take advantage of OS-specific capabilities regardless of what CTI interface they happen to use, so portability benefits are limited only to the CTI portion of an application