A connection is not fully established until both parties are communicating. To reach that point, the establishment of the call goes through several stages, as does the clearing (termination) of the call. A call's events cause it to transition through call states as it comes into existence, is used to exchange information, and terminates. This topic lists and describes the various call states.
Call-state transitions result from both solicited and unsolicited events. A solicited event is one caused by the application controlling the call (as when it invokes TAPI operations), while unsolicited events are caused by the switch, the telephone network, 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 certain specific states.
Different call states indicate that connections exist to different parts of the switch. For example, a dial tone is a particular state of a switch that means the switch is ready to receive digits.
Whenever a call changes state, the service provider reports the new state in a callback to tapi32.dll. Due to the asynchronous way in which these reports arrive and are forwarded to the tapi32.dll client applications, the programming model the application developer should follow is not one that presumes a rigid call state machine, but one where the application can react to the events reported to the application. In other words, call-state notification tells the application what the call's new state is instead of reporting the transitions between two states.
Some of the call states and events defined by TAPI are exclusive to incoming or outgoing call processing, while others occur in both cases. Several of these call states provide additional information that can be used by the application. For example, the busy state signifies that a call cannot be completed because a resource between the originator and the destination is unavailable, as when an intermediate switch has reached its capacity and cannot handle an additional call. Information supplied with the busy state includes station busy or trunk busy. Station busy means that the destination's station is busy (the phone is offhook), while trunk busy means that a circuit in the switch or network is busy. The call states defined in Win32 Telephony are listed below:
| Call State | Description |
|---|---|
| idle | This corresponds to the null state: No activity exists on the call, which means that no call is currently active. This state occurs at the end of a call, but never at the beginning of a new call. If a service provider changes the call state to idle, it must not subsequently change the call to any other state. The idle state should be the last state a call enters and it should remain in that state until TSPI_lineCloseCall is called to dispose of it. |
| offering (incoming) | When the switch informs the computer of the arrival of a new incoming call, that call is in the offering state. The offering state is not the same as causing a phone or computer to ring. When a call is offered, the computer is not necessarily instructed to alert the user. |
| For example, an incoming call on a shared call appearance is offered to all stations that share the appearance, but typically only the station that has the appearance as its primary address is instructed to ring. If that station does not answer after some amount of time, the bridging stations may be instructed to ring as well. | |
| accepted (incoming) | An application has taken responsibility for an incoming call. In ISDN, the accepted state is entered when the called-party equipment sends a message to the switch indicating that it is willing to present the call to the called person; this has the side effect of alerting the users at both sides of the call: the caller's and the called party's. An incoming call can always be immediately answered without first being separately accepted. |
| dial tone (outgoing) | Indicates that the switch is ready to receive a dialable number. In most telephony environments, this state is entered when an audible dial tone is detected by the line device. Additional information includes: |
| —normal dial tone | The "normal" or everyday dial tone, usually a continuous tone. |
| —special dial tone | A special dial tone is often used to signal certain conditions such as message-waiting. This is usually an interrupted dial tone. |
| dialing (outgoing) | The originator is dialing digits on the call. The dialed digits are collected by the switch. |
| proceeding (outgoing) | The call is proceeding through the network. This occurs after dialing is complete and before the call reaches the dialed party, as indicated by ringback, busy, or answer. |
| special info (outgoing) | The call is receiving a special information signal. A special information signal precedes a prerecorded announcement indicating why a call cannot be completed. Such announcements can be of these types: |
| —no circuit | A no-circuit or emergency announcement. |
| —customer irregularity | An announcement meaning that the dialed number is not correct. |
| —reorder | A reorder or equipment-irregularity announcement. |
| busy (outgoing) | The call is receiving a busy signal. Busy indicates that some resource is not available and the call cannot be normally completed at this time. Additional information consists of: |
| —station busy | The station at the other end is offhook. |
| —trunk busy | The network is congested. This usually produces a fast busy signal. |
| ringback (outgoing) | The station to be called has been reached, and the destination's switch is generating a ring tone back to the originator. A ringback means that the destination address is being alerted to the call. |
| connected (incoming and outgoing) | Information is being exchanged over the call. |
| onHold (incoming and outgoing) | The call is currently held by the switch. This frees the physical line, which allows another call to use the line. |
| conferenced (incoming and outgoing) | The call is a member of a conference call and is logically in the connected state (to the conference bridge). Every call in the conferenced state is linked to the parent conference call, which will be in a state such as connected, onHold, and so forth). |
| on hold pending conference (incoming and outgoing) | The conference call is currently on hold and waiting for the user to add another party. |
| on hold pending transfer (incoming and outgoing) | The call is on hold in preparation of being transferred. |
| disconnected (incoming and outgoing) | The call has been disconnected by the remote party. |
| unknown (incoming and outgoing) | The call exists, but its state is currently unknown. This may be the result of poor call progress detection by the service provider. A call state message with the call state set to unknown may also be generated to inform TAPI about a new call at a time that the actual call state of the call is not exactly known. |
Although under normal circumstances an outgoing call is likely to transition to connected through a number of intermediate states (such as dial tone, dialing, proceeding, and ringback), other paths are possible as well. For example, the ringback state may be skipped, as when a "hot phone" (or other nondialed phone) transitions directly to connected.
An application should always process call-state event notifications. Call-state transitions valid for one switch or 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 wants to make an outgoing call will succeed in allocating a call appearance from the API, but ends up 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.