Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for
4/8/2010

The Windows Embedded CE implementation of TAPI 2.0 also supports telephone devices. A telephone device is a device that supports the telephone device class and includes some or all of the following elements.

  • Hookswitch/Transducer:A means for audio input and output. TAPI 2.0 recognizes that a telephone device can have several transducers, which can be activated and deactivated (taken off-hook or placed on-hook) under application or manual user control. TAPI identifies three types of hookswitch devices that are common to many telephone sets:

    HandsetThe traditional mouth-and-ear-piece combination that must be lifted manually from a cradle and held against the ear of the user.

    SpeakerphoneEnables the user to conduct calls hands-free. The hookswitch state of a speakerphone usually can be changed both manually and by using the API. The speakerphone can be either internal or external to the telephone device. The speaker part of a speakerphone allows multiple listeners.

    HeadsetEnables the user to conduct calls hands-free. The hookswitch state of a headset usually can be changed both manually and by using the API.

    A hookswitch must be off-hook to allow audio data to be sent to and received by the corresponding transducer.

  • Volume Control/Gain Control/Mute:Each hookswitch device is the pairing of a speaker and a microphone. The API provides for volume control and muting of speakers, and for gain control or muting of microphones.

  • Ringer:A means for alerting users, usually through a bell. A telephone device might be able to ring in a variety of modes or patterns.

  • Display:A mechanism for visually presenting messages to the user. A telephone display is characterized by its number of rows and number of columns.

  • Telephone Buttons:An array of buttons. Whenever the user presses a button on the telephone set, the API reports that the corresponding button was pressed. Button-lamp identifiers identify a button and lamp pair. Of course, it is possible to have button-lamp pairs with either no button or no lamp. Button-lamp identifiers are integer values that range from 0 to the maximum number of button-lamps that are available on the telephone device, minus one. Each button belongs to a button class. Classes of buttons include call appearance buttons, feature buttons, keypad buttons, and local buttons.

  • Lamps:An array of lamps, such as light-emitting diodes (LEDs), that are individually controllable from the API. Lamps can be lit in different modes by varying the on-and-off frequency. The button-lamp identifier identifies the lamp.

  • Data Areas:Memory areas in the telephone device where instruction code or data can be downloaded to and uploaded from. The downloaded information would affect the behavior of (or, in other words, program) the telephone device.

TAPI 2.0 allows an application to monitor and control elements of the telephone device. The most useful elements for an application are the hookswitch devices. The telephone set can act as an audio I/O device (to the computer) with volume control, gain control, and mute; a ringer (for alerting the user); data areas (for programming the telephone); and perhaps a display, although the display of the computer is more capable. The application writer is discouraged from directly controlling or using telephone lamps or telephone buttons, because lamp and button capabilities can vary widely among telephone sets, and applications can become tailored quickly to specific telephone sets.

There is no guaranteed core set of services that are supported by all telephone devices, as there is for line devices (the Basic Telephony services). Therefore, before an application can use a telephone device, the application first must determine the exact telephony capabilities of the telephone device. Telephony capabilities vary with the network configuration (client versus client/server), the telephone hardware, and the service-provider software. An application determines the device capabilities of a telephone device by calling the phoneGetDevCapsfunction. The device capabilities of a telephone indicate the elements that exist for each telephone device that is present in the system and what its capabilities are. Although strongly oriented toward real-life telephone sets, this abstraction can provide a meaningful implementation (or subset thereof) for other devices, too. For example, take a separate headset that is connected directly to and controllable from the computer and operated as a telephone device. Hookswitch changes can be triggered by detection of voice energy (when off-hook) or a period of silence (when on-hook); ringing can be emulated by the generation of an audible signal into the headset; and a display can be emulated through text-to-speech conversion.

A telephone device does not have to be realized in hardware, but instead can be emulated in software that uses a mouse-driven or keyboard-driven graphical command interface, and the speaker or sound system of the computer. Such a "soft telephone" can be an application that uses TAPI 2.0. It also can be a service provider, which can be listed as a telephone device that is available to other applications through the API, and as such is assigned a telephone device identifier.

Depending on the environment and network configuration, telephone sets can be shared between the application and the hookswitch. Some minor provision is made in the API where the hookswitch can suspend temporarily the API's control of a telephone device.

See Also