What's New for TAPI Version 2.0
To provide the best performance and support on the Windows NT platform and on
future releases of the Windows 95 platform, the Win32 Telephony API and its
service providers and supporting components are fully implemented as 32-bit
components in Win32. In addition to full 32-bit implementation, Win32 TAPI includes
these many new features:
- Native 32-bit support. All core TAPI components are Win32, with full support for non-Intel
processors (running Windows NT), symmetrical multiprocessing, multithreaded
applications, and preemptive multitasking.
- 32-bit application portability. Existing Win32 full TAPI and assisted TAPI applications which currently run
on Windows 95 (using the TAPI 1.4 API) run on Windows NT on the Intel x86 family of microprocessors without modification or recompilation.
- 16-bit application portability. Existing Win16 full TAPI and assisted TAPI applications which currently run
on Windows 95 and Windows® 3.1 operating system (using the TAPI 1.3 API) run on Windows NT without
modification or recompilation.
- Unicode support. Win32 applications can choose to call the existing ANSI TAPI functions or to
call Unicode versions of functions that pass or return strings (functions with
a "W" suffix).
- Service processes. TAPI 2.0 adds mechanisms for notifying applications of telephony events that
do not require the application to have a window message queue, thereby
enabling background service processes to easily use TAPI services.
- NDISTAPI compatibility. The existing support in Windows NT 3.5 for ISDN WAN miniports under Remote
Access Service is preserved. NDIS WAN miniport drivers are supported under a
kernel mode service provider without modification.
- Registry support. All telephony parameters are stored in the registry. Telephony service
providers and all stored parameters can be updated across the LAN.
- Call Center support. TAPI supports functionality required in a call center environment, including
the modeling of predictive dialing ports and queues, ACD agent control,
station set status control, and centralized event timing.
- Quality of Service (QOS) support. Applications can request, negotiate, and renegotiate quality of service
(performance) parameters with the network, and receive indication of QOS on inbound
calls and when QOS is changed by the network. The QOS structures are
binary-compatible with those used in the Windows Sockets 2.0 specification.
- Enhanced device sharing. Applications can restrict handling of inbound calls on a device to a single
address, to support features such as distinctive ringing when used to indicate
the expected media mode of inbound calls. Applications making outbound calls
can set the device configuration when making a call.
- User mode components. The full TAPI system, including top-level service provider DLLs, runs in
The following are additional enhancements to existing TAPI features:
- Applications now receive LINE_APPNEWCALL messages (instead of LINE_CALLSTATE) as the first messages notifying the application of a new call.
- Applications now receive LINE_REMOVE and PHONE_REMOVE messages whenever a line or phone device has been removed from the system.
- LINECONNECTEDMODE_ constants now indicate when a call has been placed in the onhold state by the remote party. Also, an additional LINECONNECTEDMODE_ constant
indicates to applications when entry into the connected state was confirmed by the network, or if it is just being assumed because
confirmation from the network is impossible.
- Applications now receive notification that ringing has stopped on a line
device by receiving a LINE_LINEDEVSTATE message with the dwParam1 parameter set to LINEDEVSTATE_RINGING and both dwParam2 and dwParam3 set to zero.
- The LINEDEVCAPS, LINEADDRESSCAPS, and PHONECAPS structures now include a listing of device classes supported by the device,
with each supported device class terminated by a zero byte and the final class
terminated by two zero bytes. A typical list for a voice modem might be:
Applications can scan this list to see if a particular device supports device
classes required for the application to properly function.
- The LINEFEATURE_, LINEADDRFEATURE_, and LINECALLFEATURE_ sets of constants
have been extended to allow applications to detect when various "flavors" of a
function are available for use. For example, applications will be able to detect
not only that a call can be transferred, but whether it is permitted to resolve
the transfer as a three-way conference.
- Applications can carry out a "one-step transfer" by using
LINECALLPARAMFLAGS_ONESTEPTRANSFER with the lineSetupTransfer function.
- Applications can carry out a "no hold conference" by using the
LINECALLPARAMFLAGS_NOHOLDCONFERENCE option with the lineSetupConference function, allowing another device, such as a supervisor or recording device,
to be silently attached to the line.
- Applications can carry out a "transfer through hold" (on the systems with this
capability) by using the linePickup function with a NULL target address. Check for the LINEADDRFEATURE_PICKUPHELD
bit in LINEADDRESSCAPS and LINEADDRESSSTATUS for this capability.
- The PHONECAPS structure now includes an indication of which hookswitch states can be set for each hookswitch device, and which can be detected and reported. Previously, applications could detect only the existence of each device
without being able to determine which characteristics could be only monitored and
- The PHONESTATUS structure now also includes a dwPhoneFeatures member that indicates which phone operations can be performed at the
particular moment in time that phoneGetStatus is called.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages