The Telephony API line and phone device classes only provide control operations for these devices. However, phone devices and calls on line devices are capable of carrying media streams, i.e., information streams (voice, data, video, etc.). Access to these media streams is not provided by the Windows Telephony API. Instead the application must use other Windows APIs to provide this access or otherwise manage these media streams (such as the waveform API or the higher-level MCI interface). The Telephony API is used to establish calls independent of the call's media mode (e.g., voice, data, ...).
For example, for line devices, an application first uses the Telephony API to establish a connection to another station. Once a call is established, the application can then use the waveform API (or the MCI waveaudio API) on the associated wave device (or MCI waveaudio device) to play back (send) and record (receive) audio data over the connection. Similarly, if the connection media stream is from a fax or data modem, an application would use a fax API or data modem API (as appropriate) to deal with the media stream.
To provide both telephony API functions and media stream access to a phone or to a call on a line device, the service provider for the phone or line will have to implement both the Telephony SPI and the appropriate media stream SPI. The physical device then simultaneously supports multiple device classes, e.g., the line device class and the wave device class. Since these APIs are orthogonal, limited coupling exists at the API level between the apps' usage of these APIs. Multiple applications that share calls and media streams in non trivial ways will likely need to coordinate their activities at the application level to prevent conflicting usage of the Telephony API and the media stream API.
The Telephony API reports media stream type changes to participating applications. This process is sometimes referred to as call classification. The mechanism used to determine the type of a media stream (e.g., voice, fax, data modem, etc.) is service provider specific. A service provider may filter the media stream for energy or tones that characterize the media type. Alternatively, the determination may be made by information exchanged in messages over the network, by the use of distinctive ringing, or by knowledge about the caller or called ID, etc.
The Telephony API also provides limited support for control of the media stream that may exist on a call. This is provided to avoid latency problems that may arise in client/server configurations where the application would be forced to go through the stream's media API. An application can request actions on a call's media stream triggered by events normally reported via the Telephony API, such as the detection of a tone or DTMF digit, the transition of the call to a specified call state, etc. For example, an application can request that a call's media stream be suspended when a # DTMF digit is detected on the call, and that the media stream be resumed when a * DTMF digit is detected on the call. Note that some implementations or configurations will be unable to provide any media control functions or media access to the phone or line. Providing media control is optional to the service provider; it should provide the largest performance benefit for client/server implementations. Since it is optional and since only limited control is provided, its usage is generally discouraged. If at all possible, apps should use the stream's media API instead.