State

Session or call state indicates the current status of a session, such as "offering" or "connected." Proper handling of state information is vital to the proper functioning of most TAPI applications.

A session's events cause it to transition through various states as it comes into existence, is used to exchange information, and terminates. These state transitions result from both solicited and unsolicited events.

A solicited event is one caused by the application controlling the session, such as when it invokes a TAPI session operation. Some session operations require a particular state.

Unsolicited events are caused by the switch, the telephone network, the user pressing buttons on the local phone, or the actions of the remote party. Some operations on line devices, addresses, and calls may first require that the line, address, or call upon which they operate be in specific states.

Whenever a service provider detects a session state change, it reports the change to TAPI and TAPI reports the new state to all owner and monitor applications in a message. The application must react to these messages appropriately. Please see Event Notification under TAPI Initialization for information on controlling which events are reported to an application.

An application should always process state event notifications. State transitions valid for one physical configuration may be invalid for another. For example, consider a line from the switch that (using a simple Y-connector) physically terminates both at the computer and at a separate phone set, creating a party line configuration between the computer and the phone set. The computer termination and, therefore, the application using TAPI may not know of the activities on the line handled by the phone set. That is, the line may be in use without the service provider being aware of it. An application that attempts to make an outgoing call will succeed in allocating a call appearance from TAPI, but this results in sharing the active call on the line. In this case, blindly sending a DTMF dial string without first checking for a dial tone may not result in intended (or polite) behavior.

Due to the asynchronous way in which these state events arrive and are forwarded to the TAPI client applications, the application developer should not assume a rigid progression from one state to another, but one where the application can react to the events reported to the application. In other words, call-state notification should be viewed as telling the application the call's new state instead of as reporting the transitions between two states.

All telephony service providers must supply this information.

TAPI 2: lineGetCallStatus, lineGetCallInfo, LINE_CALLSTATE message, LINECALLSTATE_ Constants

TAPI 3: ITCallInfo::get_CallInfoLong (CIL_CALLID member of CALLINFO_LONG), ITCallStateEvent notification, CALL_STATE enumerator