Features in TAPI Version 2.0 and Later

TAPI version 2.0 and later contain these features:

• Native 32-bit support. All core TAPI components are Win32, with full support for non-Intel processors (running Windows NT and Windows 95), symmetrical multiprocessing, multithreaded applications, and preemptive multitasking.
  To provide the best performance and support on the Windows NT and the Windows 95 platforms, the Win32 Telephony API and its service providers and supporting components are fully implemented as 32-bit components in Win32.
• 32-bit application portability. Existing Win32 full TAPI and assisted TAPI applications which currently run on Windows 95 also 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 user mode.

The following are additional version 2.X enhancements to existing TAPI features (now applicable to Windows 95 platforms running TAPI 2.0 or later):

• 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:

  "tapi/line\0comm\0comm/datamodem\0wave/in\0wave/out\0\0" 
   

  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 not set.
• 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.