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. For example, the answer operation can be performed only on an offered session, but a transfer will fail if the session is in that state.

A session's state changes as a result of events. Events can be solicited or unsolicited. Solicited events are caused by the application controlling the session, such as when it invokes a TAPI session operation. 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.

Whenever a service provider detects a session state change, it reports the change to TAPI and TAPI issues an event notification to all owner and monitor applications. The application must react to these notifications 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 that physically terminates both at the computer and at a separate phone set, creating a party line configuration between the computer and the phone set. An application running on the computer may not know about phone set activities. 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. Blindly sending a DTMF dial string without first checking for a dial tone may not result in intended (or polite) behavior.

An application should not assume a rigid progression from one state to another. State events arrive and are forwarded asynchronously and notifications may not be received in a predictable order. Therefore, call-state notifications 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.x:  **lineGetCallStatus, lineGetCallInfo, LINE_CALLSTATE message, LINECALLSTATE_ Constants

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