Smart Appliances
Product Information
Telephony API
A telephony card is a device designed specifically for doing voice processing over telephone lines. The telephony API is unique in its nature because it is dynamic; instead of having procedures that are internal to the computer, it interfaces with non-computer devices (e.g. the phone), which can be unpredictable at times. The Telephony API is an object-oriented application that can be used in the Windows 95, 98, 2000, or NT platforms. There are two parts to the Telephony API application, the core API or the TAPI, which is the call model (the call and answer portion of the application) and the TSP (telephony service providers), which allows what the caller wants to be done. The telephony service providers are components that allow hardware functionality.
In determining how the application should work, we must first discuss the different models that the TAPI uses to actually complete the processes of the application. The first model that the TAPI uses is the LineApp. This model is the most important part of the TAPI procedure because it determines when a call begins and ends. Each LineApp is a separate call that user comes in (via a phone) and starts the TAPI session. The initialization occurs when the user phones into the application (a function identifies the call and is called) and ends when the phone hangs up (a function is called to determine if the user is still on the line). Because of this, there may be multiple call-ins into the system at the same time, since each LineApp is separate. The next model that is used is the Line model. This allows the application to recognize the users decisions. Essentially, the Line model allows a method for a conveyance of a media stream. The TSP determines how the media stream to be implemented, however. The Line can be implemented many times concurrently in a LineApp, since the LineApp are separate. The Line model is used mostly as a control for the call coming in, so media would not be mixed together in and sort of way. The next model of the TAPI is the phone model. This model is a representation of the physical equipment that is used by the user. Since phone objects can be used without the use of calls, such as a telephone handset interfacing with a voice mail system, or retrieving voice mail messages, the phone model allows the user to also do this. Writing a TSP to expose the physical properties of telephone devices to the TAPI applications can do this. The final model that the TAPI needs is the call model. This is done because not all calls are one-to-one, such as call waiting and conferencing. When the application creates a call, functions are called to create the call. If the application is running at the time, a function will be called to tell the application that a call is being sent. These call objects are on the Line model, so they are also for control.
The process of connecting the Telephony API with the telephone is using is quite intriguing. The first call that the TAPI application makes is to create memory space in the application and load the installed TSPs. The TSPs will respond with the number of line and phone devices it is going to use, and the TAPI will assign a device ID for each of them. The TAPI will also recognize the TAPI session that the user will be on. Since, TAPI’s are strongly event driven, telephony events reported to the applications include changes in existing calls, new incoming calls, connections and disconnections. The TAPI uses a hidden window to drive a callback mechanism, because of this, the application must meet conditions that will allow the application to run: the application must dispatch messages and the thread that calls the initializing of the line must handle the callbacks.
Since users most of the time have more that one telephony line device installed on a computer (modems and telephone lines), the TAPI does not pick a line that is there, but rather picks a line that can proceed with the call. Functions that are in the TAPI allow the application to determine which device can do what; this is done by querying the device for their capabilities. Once the desired device is selected, the API negotiates with the application to determine the high and low versions that user wants to input.
After the line device was selected by the TAPI, a line can be opened. The problem, now, is that the user and only the user (owner of the home/office) should be able to access the server. Initially, the information will be stored in a function, after this function is called, another function will be called to determine that the user has the accessibility to the application. If the application needs to make a data connection, then an application calls an API function that will allow this. When a connection is made, the TAPI is no longer used unless something happens to the line that requires intervention. The API’s that are appropriate to the media for interest handles the media stream. The program that will be used is the speech engine. This will allow the application to take the voice of the user, which is in an analog form, convert this into a digital form, and then process this information for the application.
After the user inputs his information, the call has to be dropped either by the user ending the call or the application using an API call to end the telephone call. The way that the application ends the call by calling a function that drops the call. This does not mean that the application ends the call immediately; rather it starts a function that starts a series of call states to determine if the user is still entering the information or on the line. After the function is true, information cannot be processed and API functions will not work on the call. This is where cleanup occurs because the notification will be received no matter how the call was dropped and there is no action that can be taken on the call that may change the call state.
