Platform SDK: TAPI |
When a call is in the connected state, information can be transported over the call. A call's media type provides an indication of the type of information (for example, its datatype, or higher-level protocol) of this media stream.
TAPI allows applications to be provided with a notification about changes in a call's media type. The notification provides an indication of the call's new media type. The service provider decides how it wants to make this determination. For example, the service provider could use signal processing of the media stream to determine the media type, or it could rely on distinctive ringing patterns assigned to different media streams, or on information elements passed in an out-of-band signaling protocol. Independent of how the media type determination is achieved, the application is simply informed about media type changes on an existing call.
See LINEMEDIAMODE_ Constants for a list of currently defined TAPI media types or modes. Service providers may implement provider-specific media types for highly specialized devices. Information on these will be found in device documentation.
The media types defined by TAPI include.
An application can enable or disable media monitoring on a specified call with lineMonitorMedia. The application specifies which media types it is interested in monitoring, and when media monitoring is enabled, the detection of a media type change causes the application to be notified with the LINE_MONITORMEDIA message. This message provides the call handle on which the media type change was detected as well as the new media type.
There is a distinction between the media type of a call as reported by lineGetCallInfo and the media type event reports by LINE_MONITORMEDIA messages. A call's media type is determined exclusively by owner applications of the call and is not automatically changed by media monitoring events. The one exception is the initial media type determination that can be performed by the TAPI dynamic-link library to select the first owner of a call. One could argue that in this case, the library is the owner of the call.
Default media type monitoring is performed for the media types for which the line device has been opened. This allows an incoming call's media type to be determined before the call is handed to an application based on what the application demands. The scope of the media monitoring of a call is bound by the lifetime of the call. Media monitoring on a call ends as soon the call disconnects or goes idle.
An application can obtain device identifiers for various device classes associated with an opened line by calling lineGetID. This function takes a line handle, address, or call handle and a device class description. It returns the device identifier for the device of the given device class that is associated with the open line device, address, or call. If the device class is "tapi/line," then the device identifier of the line device is returned. If the device class is "mci/wave," then the device identifier of an mci waveaudio device is returned (if supported), which allows activities such as the recording or playback of audio over the call on the line.
The application can use the returned device identifier with the corresponding media API to query the device's capabilities and subsequently open the media device. For example, if your application needs to use the line as a waveform device, it must first call waveInGetDevCaps and/or waveOutGetDevCaps to determine the waveform capabilities of the device. The typical waveform data format supported by telephony in North America is 8-bit m-law at 8000 samples per second, although the wave device driver can convert this sample rate and companding to other more common multimedia audio formats.
To subsequently open a line device for audio playback using the waveform API, an application calls waveOutOpen. The implementation of waveOutOpen is device specific, and there are a variety of options for implementing this function.