USB Handset Peripherals and Windows
Updated: January 11, 1999
.gif)
File name: USBtelephony-v091.doc
1.2 MB
Microsoft Word file
Get Office File Viewers
About This Download
On This Page
Purpose and Definitions Introduction to TAPI and USB Handsets Planned Operating System and Application Support Basic Requirements for USB Handsets
Purpose and Definitions
Microsoft has published a draft paper that introduces architecture for support planned for USB-connected telephony peripherals in future versions of the Microsoft Windows 2000 operating system. The draft paper presents the information--including Audio and HID Class firmware requirements and options--which a hardware manufacturer needs to know to build a USB handset device that will work with Windows native support and with Windows-based TAPI applications.
For the purposes of this article, the term "USB handset" is used to refer to a device that implements phoneset-like user interface capabilities, connects to a PC using USB, and does not connect directly to a telephony network. The use of the word "handset" is not meant to exclude devices with other form factors, such as headsets or speakerphones.
Introduction to TAPI and USB Handsets
In future releases of Windows 2000 operating systems, Microsoft is planning to provide built-in support for USB-connected handset devices. Support will initially be targeted for USB composite devices that implement audio functionality compliant with the USB Device Class Definition for Audio Devices, Version 1.0, plus a human interface compliant with the USB Device Class Definition for Human Interface Devices (HID), Version 1.0 and Version 1.1.
Such devices will be supported by enhanced TAPI functionality and by TAPI-enabled applications such as future versions of Microsoft NetMeeting conferencing software.
NOTE: All features referred to in this paper are in a planning stage only, and Microsoft has not committed to delivering these features in any form in any particular release of any product.
Windows 2000 includes TAPI 3.0, a set of services and APIs for building telephony applications. TAPI 3.0 allows applications to make use of telephony infrastructure for both call control and media streaming in a device-independent, language-neutral manner. In addition, TAPI 3.0 includes native support for IP telephony protocols.
To encourage the development of USB telephony devices and to facilitate adoption of PC-based IP telephony, Microsoft is planning to add support for USB-connected handsets to Windows. The purpose of these devices is to improve the user experience for PC-based telephony by presenting the user with a familiar audio streaming and call control interface. Experience has shown that many users prefer a phoneset-like interface for making telephone calls because of the familiarity, simplicity, privacy, and protection from echo that such an interface can provide.
Optionally, a phone keypad on the device can provide familiar dialing capabilities. Devices without a phone keypad are also useful; dialing can be accomplished using voice recognition, TAPI 3.0 directory integration, or the numeric keypad on a PC keyboard.
Planned Operating System and Application Support
Planned support in Windows will consist of default control of user interaction for the USB-connected telephone, plus the ability to access and control the device in applications that are aware of such a device. Users will be able to place telephone calls as soon as they have plugged the device into a PC USB port; no additional software will be necessary. Third-party software will be able to take full advantage of the USB-connected telephone as a user interface mechanism by using device-independent, language-neutral TAPI interfaces.
The new TAPI interfaces and TAPI functionality dealing with USB handsets will be tightly integrated with the existing TAPI APIs and architecture, so that TAPI-enabled applications can easily be extended to take advantage of USB handsets. Such TAPI-enabled applications will include future versions of NetMeeting.
The following illustrates planned future support for USB phones in the overall TAPI architecture. New additions to the architecture are shown in bold.
Figure 1: Map of Future TAPI infrastructure for USB Handsets
If the user is not running any third-party telephony application that takes responsibility for handling the USB phone via the phone device object in TAPI, then Windows will provide default handling for the USB phone using a component called the Phone Manager. The Phone Manager will handle tasks such as generating a dial tone on the USB handset audio device and gathering digits from the handset's keypad or another source. The Phone Manager will be a system service, but the execution context and feature set have not yet been determined.
Basic Requirements for USB Handsets
The full draft document presents the information that a hardware manufacturer needs to know to build such a device. Following the guidelines presented in the document will help to ensure that your device works with Windows native support and with Windows-based TAPI applications. The document also outlines the Audio and HID Class firmware requirements and options for such a device. Here is a brief summary:
-
Implement bi-directional, full-duplex audio functionality compliant with the USB Audio Class specification. Bi-directional means both capture and render. Full-duplex means that the device can both capture audio and render audio at the same time. For both capture and render, the device must support at least the following formats:
-
16 KHz, 16-bit linear mono PCM
-
8 KHz, 16-bit linear mono PCM
-
-
Implement a HID-compliant hook switch to indicate if the telephone is on hook or off hook. This switch needs to be implemented both as an Input and Feature control in order to enable TAPI to read the initial state of the hook switch when the device is plugged in.
-
To allow TAPI to associate the audio and HID device as belonging to the same telephone, the audio device and HID device must present the same Vendor ID, Product ID, and Revision to the PC, and must be part of the same compound or composite device. The example descriptors in the full document show how to do this.
-
Audio and HID are completely separate on the telephone device, and there are no dependencies or interactions between them from the device's point of view. The PC controls all audio streaming. For example, there is no dial tone generation on the device; the PC outputs a dial tone to the audio device based on an indication from the HID hook switch that the telephone is off hook.
The standard Audio and HID device classes are used to ensure the highest level of interoperability between applications and handsets. Hardware products that conform to the Audio and HID device classes benefit from increased support from Microsoft and industry-standard tools.
A simple USB handset device could be designed in a form factor similar to a standard telephone handset or alternatively as a headset.
Call to action for USB handsets
-
Download and review the complete USB handset hardware specification draft document, Support for USB Telephony Devices in Microsoft Windows.
