2.3.2 Device Classes
The Windows Telephony SPI defines two new device classes; the line device class and the phone device class. The SPI defines a collection of functions and messages for line devices and another collection of functions and messages for phone devices. Each of these defines a so-called behavior or abstract data type. In principle, a line device is any device that implements the line behavior defined by the SPI; a phone is any device that implements the phone behavior defined by the SPI. Note that how this behavior is implemented and mapped onto real world telephony technology is entirely up to of the service provider. As will be illustrated later, the SPI can be mapped to a wide range of environments, including ones not traditionally thought of as telephony environments. Therefore, any definition provided herein as to what a line or phone device actually represents should be taken primarily as an example.
The line device class can represent a pool of resources. These resources can include compute power and memory used by the service provider for controlling the physical resources, but more importantly, they would also contain a pool of identical communication channels (signaling and/or information channels) between the API and the switch or network. In many common cases (like POTS), a service provider is likely to model a line as having only one channel.
The fact that channels belonging to a line are identical implies that channels are interchangeable. The line's service provider that models a pool of channels as a line device can do so to simply provide pooling of shared resources. A service provider may also decide to allow the TAPI DLL to request that multiple channels be combined into a single call to provide a call with wider bandwidth available for the call, this technique is often referred to as inverse multiplexing. A line's resources are dynamically allocated when the TAPI DLL makes or answers a call. With a line's resources having identical capabilities and being interchangeable, there is no need for the TAPI DLL to explicitly identify which channels are to be used. Resources are owned and assigned by the service provider for the line device in a way that is transparent to the TAPI DLL. This eliminates the need to introduce another level of naming (i.e., the naming of channels) by the SPI.
The phone device class represents a device independent abstraction of a telephone set.
The Telephony SPI treats line and phone devices as independent devices. Service providers that fully implement this independence can offer uses of the line and phone devices to the applications not defined by "normal" telephony protocols. For example, you can use the handset of the desktop's phone as a wave form audio device for voice recording or playback, and, depending on the implementation, you may be able to do it without the switch knowing that the phone is in use. In such an implementation, lifting the local phone handset may not automatically send an offhook signal to the switch. This feature also allows your application to ring the local phone independent of incoming calls. Capabilities of actual service providers may be limited by the hardware and software used to interconnect the switch, the phone, and the PC. The SPI includes functions to retrieve device capabilities that allow clients to determine whether such a usage model is supported.