TAPI 2.0 and the Windows NT and Windows 95 operating systems provide a comprehensive foundation for telephony applications, which allows developers to create a wide range of products. The exhaustive list of telephony features supported by TAPI means that a developer can telephone-enable virtually any general purpose application. And TAPI provides unrivaled supplementary and extended support for . telephony-centric applications.
TAPI 2.0's support of Unicode makes it easier to create applications that work globally. And, of course, adding to the comprehensiveness of the Windows telephony platform are the APIs and other complementing support from WOSA elements. Additionally, ActiveX Controls for telephony, provided by a variety of vendors, allow corporate developers to put together powerful telephony applications even faster and more easily using tools they already understand.
To provide developers with maximum flexibility, telephony support can be implemented at four levels with TAPI:
Assisted Telephony is a small set of functions that provide very basic telephony functions to primarily non-telephonic applications. This valuable feature is designed to make the establishment of voice calls and of media calls available to any Win32-based application, not just those dedicated to telephonic functionality. In other words, Assisted Telephony lets applications make telephone calls without needing to be aware of the details of the services of the full Telephony API.
Assisted Telephony extends telephony to word processors, spreadsheets, databases, personal information managers, and other non-Telephony applications. For example, adding an Assisted Telephony function (tapiRequestMakeCall) to a spreadsheet lets users automatically dial telephone numbers stored in the spreadsheet (or in a connected database). Assisted Telephony is the easiest and most efficient way to give telephonic functionality to non-telephonic applications.
Basic Telephony Services, rather than Assisted Telephony, is used for applications whose telephony functionality goes beyond just the making or receiving of a call. The complete TAPI defines three levels of service, of which Basic Telephony is the first.
Basic Telephony Services are a minimal subset of the Win32 Telephony specification. Since all service providers must support the functions of Basic Services, applications that use only these functions will work with any TAPI service provider. The functionality contained in Basic Telephony roughly corresponds to the features of "Plain Old Telephone Service" (POTS) such as make call, hang up, and answer call.
Basic Services include:
Today, many programmers will use only the services provided by Basic Telephony. And, at a minimum, service providers are be designed to support all of the Basic Telephony functions. Other application developers, such as those writing code for PBX phone systems, will need the functions of Supplementary Telephony.
Supplementary Telephony Services include the bulk of what TAPI offers—a very complete set of functions to enable a wide range of powerful, easy-to-use telephony applications. In Win32 Telephony, supplementary functions are those whose form and functionality have been defined by the API description, but which are not required in Basic Telephony. They are functions that developers of telephony applications and service providers may choose to implement to suit the design of their custom products. So, in contrast to Basic Telephony functions, Supplementary Telephony functions are optional.
Supplementary Services include:
TAPI contains a well-defined API extension mechanism that allows service-provider vendors to extend the Telephony API using device-specific extensions. Extended Services (or Device-Specific Services) include all extensions to the API defined by a particular service provider. Since the API defines the extension mechanism only, the definition of the Extended-Service behavior are completely specified by the service provider.
TAPI's extension mechanism allows service-provider vendors to create functions not directly defined by the Telephony API. This flexibility provides the power developers need to create their own custom, value-added marketplace solutions.
TAPI 2.0's comprehensiveness is carefully thought out. For example, it provides developers with an excellent level of control—while guarding against allowing excessive controls that might limit applications to specific hardware settings.
Some of the more difficult decisions to be made by the architects of a telephony API relate to the level of control over specific hardware that is to be permitted to applications.
For example, developers of applications that use telephony boards designed to the MVIP specification are accustomed to controlling which "timeslot" on a high-bandwidth channel is carrying the signal for a particular call to and from the board in question. Such applications would not be easily portable to, say, a modem or PBX phone. An API that required (or even encouraged, by making available) such detailed control would not facilitate the development of highly portable shrink-wrapped commercial telephony applications. The precise control of such low-level details is more appropriately assigned to an interface between a low-level device driver and the hardware, rather than the relatively high-level interface between the operating system and application programs.
On the other hand, if the API gives applications insufficient control of call details, some beneficial functionality may be lost. Users complain of being unable to perform certain functions through their software that are easily performed through the telephone itself. An example of this is in the area of establishing and controlling multiparty audio conference calls. It is possible to create a very simple conference call API, but this may not be flexible across a variety of platforms (PBX and Centrex conferencing models differ in significant ways), to allow the addition and removal of arbitrary calls from the conference, and so forth. The ability to control certain low-level elements such as the timing and duration of Touch-Tone (DTMF) signals is also important to compatibility with other equipment.
A successful CTI API must implement basic call control features—but all this brings to users is, fundamentally, the ability to move the telephone user interface from the keypad to the PC screen. There are certainly benefits in this alone, such as allowing the interface to be context-specific (showing only the functions actually available at the moment) and eliminating the need to remember arcane multidigit feature activation codes and key-press sequences. Most CTI APIs to date have been limited to call control. Realization of the most significant benefits of computer telephony integration requires, however, the inclusion in the API of access to the "media stream"—the information content of the call.
Media-awareness comes in several flavors. First are those features that are unique to the telephony environment, such as the monitoring and generation of dual-tone multifrequency ("Touch Tone") digits and call progress signals. Since these features are not included in any other general-purpose operating system API, it is appropriate for the telephony API to include them directly.
Second are features that have been part of PC operating systems for many years and for which there are well-established APIs. These include the playing and recording of sound and the sending and receiving of data of various kinds. Replicating these features in the telephony API would be redundant and confusing to programmers, and would inhibit the use of the infrastructure and tools that already exist for use with those other APIs. For example, developers of modem communications software are much more likely to migrate their code from directly controlling the modem to using a telephony API for call control if their investment in finely-tuned terminal emulation and file transfer code, which uses existing operating system APIs for data transfer, is preserved. Developers of telephony applications appreciate being able to use higher-level audio-related features such as speech recognition, text-to-speech, and mixer control, which have already been developed for use with local audio equipment (microphones and speakers), to manage telephone calls as well. A well-architected CTI API must allow telephony device drivers to be associated with linked device drivers that are accessed via these media stream APIs, and provide means for applications to become aware of the device identifiers associated with the device to be used via these other APIs to give access to the media stream of the call.
Windows TAPI supports telephony as a service at the operating system level, giving it the ability to handle media streams and support multiple applications.
There are two types of information transmitted over the phone network. There is information that is carried from one endpoint to another, such as a voice conversation, a data modem session or a fax. This is known as a media stream. The other type of information is signaling. Unlike a media stream, signaling only moves between an endpoint on the network and the network itself. Signaling comprises the housekeeping instructions to and from the network, such as dialing or transferring a call or delivering Caller ID.
TAPI provides access to the signaling for setting up calls and managing them, as well as preserving existing media stream functionality to manipulate the information carried over the connection TAPI establishes. This allows applications to not only dial and transfer calls, but also to support fax, desktop conferencing or applications that use the telephone set dial pad to access voice-prompted menus.
TAPI's tight integration with other Windows APIs allows it to seamlessly invoke other APIs and Win32 functions, such as the Network Driver Interface Specification (NDIS), COMM, Wave Audio, MIDI, and MCI to handle media, sound, and video.
Microsoft has steadily evolved its Telephony API, as it has evolved its Windows operating systems. TAPI's evolution has consistently been guided by the active involvement of leaders from throughout the telecommunications industry, including close consultation with independent hardware and software vendors, and service providers. The result has been an ever more powerful and flexible telephony platform for developers and end users.
TAPI 1.3 was released as a standalone SDK in November 1993. It focused on call-control applications such as PBX support, but handled only 16-bit applications and didn't provide "dialing properties."
TAPI 1.4, released as part of Windows 95, provided substantial enhancements, including:
Both TAPI 1.3 and 1.4 provided excellent first-party call control. Some companies created client/server applications, but had to provide additional "plumbing" on their own—something that is being solved with TAPI 2.0.
TAPI 2.0 is built into Windows NT Server 4.0 and Windows NT Workstation 4.0 (and will soon be made available for Windows 95). For developers, the TAPI SDK is integrated with the Win32 SDK developer's platform. That platform is part of Microsoft Developer Network (MSDN), for Windows 95, Windows NT Workstation, and Windows NT Server. The SDK includes headers, libraries, sample code, and documentation. TAPI 2.0 includes these enhancements:
Part of evolving an API is to build into it a solid path for extensibility. Not even the most rich and robust of CTI APIs will ever encompass every feature that might be created by the telephony industry. So a CTI API must grow over time to include new features that emerge and gain acceptance. TAPI was designed from the start to grow—to allow new fields to be added to data structures in a straightforward and backwardly-compatible manner, for new messages and events to be created, and so on. TAPI also allows a mixture of old and new drivers and applications to coexist through a version negotiation mechanism.
TAPI also allows developers of telephony drivers to include unique or advanced features in such a way that the presence of these features can be detected by applications that have been designed to use them, without blocking older applications that aren't able to take advantage of them.
In the months following TAPI 2.0's release, Microsoft plans to release additional enhancements, which will include:
Continuing to evolve the Telephony API is part of Microsoft's commitment to always providing the best platform for whatever services and applications the market creates a need for. Microsoft works constantly with customers and developers, seeking insights into how the platform should evolve.