Microsoft Telephony Overview

Links

TAPI Architecture:
http://www.tapiex.com/support/TAPI_Architecture.htm#AssistedTelephonyServices

TAPI Quick Start.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tapi/tapi3/tapi_quick_start.asp

TAPI 3.1
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tapi/tapi3/tapi_3_1_start_page.asp

http://www.exceletel.com/products/TeleTools/SamplePrograms/Index.htm

www.codeproject.com/useritems/tapi.asp

Microsoft Telephony Overview

Telephony integrates computers with communications devices and networks. Under classic telephony, the device was a telephone and the network was the Public Switched Telephone Network (PSTN). Modern telephony continually expands the range of devices and networks, and currently covers devices such as cameras and networks such as the Internet.

Possible telephony applications include:

·  Multicast multimedia IP conferencing

·  Voice calls over the Internet (VoIP)

·  Automatic Call Distribution (ACD) Center client and server applications

·  Basic voice calls on the PSTN

·  PBX-like controls such as call park and selective forwarding on a corporate phone network without the need to invest in specialized hardware

·  Interactive voice response (IVR) systems

·  Real-time collaboration

The following diagram illustrates Microsoft Telephony architecture, and is hyperlinked as a basic roadmap to the material in the TAPI documentation. Please note that TAPI is not limited to PSTN, ISDN, or TCP/IP transport.

Platform SDK Release: February 2003

TAPI Overview

A Telephony Application Programming Interface (TAPI) is a set of programming

libraries that allow a computer and a telephony device such as a phone line or

telephone to interact. TAPI is quite complex; it supports voice and data

transmissions and even has call management capabilities such as call waiting

and voicemail.

Components of TAPI

API

The application programming interface (API) is a set of functions that allows programmers to access telephony functions.

TAPI server

The API allows a program to make hardware requests, and it is the job of the TAPI server to interpret those requests and send them to the specific hardware device. The TAPI server interacts with hardware through a layer called a service provider interface.

Service provider interface

The purpose of the service provider interface (SPI) is to take generic requests from theTAPI and translate them into the specific protocols that control the hardware device. Each SPI is written by the telephony device manufacturer.

Hardware

TAPI can control and monitor lines of various types of telephony devices and services, including POTS, ISDN, digital T1, and even private branch exchanges (PBXs) given a compatible SPI.

There are limitations to TAPI - features in ISDN that are not available in POTS, and TAPI cannot make a POTS line act like an ISDN connection.

Media Service Provider (MSP)

A TAPI 3 media service provider (MSP) allows an application considerable control over the media for a particular transport mechanism. An MSP always exists paired with a Telephony Service Provider (TSP). Just as a TSP is an abstraction layer for call control, the MSP controls media without need for device-specific coding.

An MSP enables media control through the use of special terminal, stream, and substream interfaces defined by TAPI.

Media capabilities are quite different under TAPI 2.2 (TAPI/C) as opposed to TAPI 3 (COM), largely because the COM API has access to media service providers (MSPs).

The two most important concepts for an application are the media type (or mode) and the stream.

The media stream is the actual stream of information that travels on the line. An MSP can provide direct access to the stream. TAPI 2.2 applications have some access, but primarily reference other APIs to implement such controls.

These APIs include the Waveform API, the Comm API, and the Media Control Interface (MCI). The Waveform API is used for multimedia programming, the Comm API is the set of communications functions provided by the Microsoft Platform SDK, and the MCI provides a high-level generalized interface for controlling media devices.

For example, for line devices, an application can use TAPI 2.2 to establish a connection to another station. Once the connection is established, the application can then use the Waveform API (or the MCI Waveaudio API) on the associated device to play back (send) and record (receive) audio data over the connection. Similarly, if the connection's media stream is from a modem, an application would use the modem configuration extensions of the Comm API to control the media stream.

To provide TAPI 2.2 with media-stream access to either a phone or a call on a line device, the service provider must implement both the Telephony SPI and the appropriate media stream SPI or DDI (device-driver interface). The service provider can support lines and phones simultaneously.

Because these device classes and media stream operations function independently of one another, coordination of their usage must occur at the application level. Multiple applications that share calls and media streams in nontrivial ways will likely need to coordinate their activities at the application level to prevent conflicting usage of TAPI and the media stream API in use.

TAPI reports changes in the type of media stream (voice, fax, data modem, and so on) to participating applications. This process is sometimes referred to as call classification. The mechanism used to determine the type of media stream is specific to the service provider. For example, a service provider may filter the media stream for energy or tones that characterize the media type, or it may use distinctive ringing, information exchanged in messages over the network, or knowledge about the caller or called ID to make this determination.

TAPI Programming

TAPI 3.x Versus TAPI 2.x

The COM-based telephony API, TAPI 3.x, is available starting with Microsoft® Windows® XP. TAPI 3.x provides greatly enhanced development tools for the modern world of communication programming, where a "call" may be a video stream on an IP-based network, and there is no phone set involved in the session. Generally speaking, application writers will find TAPI 3.x provides better support to implement flexible communications controls.

However, TAPI 2.x may be the right choice in some situations. If minor modifications are needed for a legacy application, or there are legacy platforms to support, conversion to the COM API may not be cost effective.

TAPI 3.1 Overview

TAPI version 3.1 is a COM-based API that merges classic and IP telephony. Possible applications range from simple voice calls over the Public Switched Telephone Network (PSTN) to multicast multimedia IP conferencing with quality of service (QOS).

For additional information on TAPI 3.1 IP Telephony capabilities, please consult the "IP Telephony with TAPI 3" white paper, which can be found on the Microsoft web site.

There are four major components to TAPI 3.1:

·  COM API

·  TAPI Server

·  Telephony Service Providers (TSPs)

·  Media Stream Providers (MSPs)

The following diagram illustrates the TAPI 3.1 architecture:

The API is implemented as a suite of Component Object Model (COM) objects. Moving TAPI to the object-oriented COM model allows developers to write TAPI-enabled applications in many languages, such as Java, Visual Basic®, or C/C++. Use of COM enables component upgrades of TAPI features. For additional information on COM, please refer to the Component Services section of the Platform SDK.

The TAPI Server process (TAPISRV) abstracts the TAPI Service Provider Interface (TSPI) from TAPI 3.x and TAPI 2.x, allowing TAPI 2.x Telephony Service Providers to be used with TAPI 3.x, maintaining the internal state of TAPI. TAPISRV is implemented as a service process within SVCHOST.

Service Providers abstract provider-specific media transport mechanisms. They typically exist in pairs – a Telephony Service Provider (TSP) for call control and a Media Service Provider (MSP) for media control.

Telephony Service Providers (TSPs) are responsible for resolving the protocol-independent call model of TAPI into protocol-specific call control mechanisms. TAPI 3.1 provides backward compatibility with TAPI 2.1 TSPs. Two IP Telephony service providers (and their associated MSPs) ship by default with TAPI 3.1: the H.323 TSP and the IP Multicast Conferencing TSP.

Media Service Providers (MSPs) provide a uniform way to access the media streams in a call, supporting the DirectShowTM API as the primary media stream handler. TAPI MSPs implement DirectShow interfaces for a particular TSP and are required for any telephony service that makes use of DirectShow streaming. Generic streams are handled by the application.

About Call And Media Controls, TAPI 3.1

TAPI 3 call and media controls are a generic set of COM objects, interfaces, and methods for making calls between two or more machines. In the context of TAPI 3, call refers not just to voice transmission over the public switched telephone network (PSTN) but to any medium and transport mechanism for which service providers exist: for example, a multimedia multicast conference running on a corporate intranet.

The five main objects in the TAPI 3 call and media control architecture are TAPI, Address, Terminal, Call, and CallHub. In addition, provision has been made for provider-specific interfaces. The diagram in About Call And Media Controls shows these objects with their associated interfaces and is hyperlinked to the object overviews and the interface reference section.

The following diagram illustrates how these objects interact, and it is hyperlinked into the relevant overview sections and reference pages.

Features

·  Abstracts both call and media functionality to allow different and seemingly incompatible communication protocols to expose a common interface to applications.

·  Based on the Component Object Model (COM) so applications can be written in nearly any language. If you require additional information on COM, please consult the Platform SDK.

·  Call control provided by Telephony Service Providers (TSPs), which implement transport-specific mechanisms.

·  Media control provided by Media Service providers (MSPs). Current MSPs use DirectShow™. DirectShow is a modular system of pluggable components called filters, arranged in a configuration called a filter graph. The filter graph manager oversees the connection of these filters and controls the stream's data flow. If you require additional information on DirectShow, please consult the Platform SDK.

Call and Media Controls Quick ReferenceTAPI 3.1

The following table lists TAPI version 3 COM interfaces by category in order of importance. The interfaces are grouped according to TAPI 3's five basic call control objects: TAPI, Address, Terminal, Call, and CallHub. Remaining interfaces are grouped according to Automatic Call Distribution (ACD) interfaces, which provide call-center functionality; enumerator interfaces, and stand-alone objects.

Telephony Application Programming Interface Version 2.2

TAPI/C is designed for use by C/C++ programmers. Previous development experience with telecommunications or other telephony applications is helpful but not necessary.

Basic Telephony Services Reference, TAPI 2.2

The Basic Telephony functions are listed by category in the following tables. A function is identified as asynchronous if it indicates completion in a REPLY message to the application. If the function always returns its result to the application immediately, the function is considered synchronous.

Following is a functional grouping of the basic telephony service functions:

·  Address Formats

·  Addresses

·  Answering Incoming Calls

·  Call Drop Functions

·  Call Handle Manipulation

·  Call Privilege Control

·  Call States and Events

·  Line Status and Capabilities

·  Line Version Negotiation

·  Location and Country/Region Information

·  Making Calls

·  Opening and Closing Line Devices

·  Request Recipient Services

·  TAPI Initialization and Shutdown

·  Toll Saver Support

Windows Configuration