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 by TAPI 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. |
| 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. |
| 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 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, which 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. |
| on hold (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). A call in the conferenced state refers to a conference call (in the connected, onHold, ... state). |
| 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 the TAPI DLL 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 (dial tone, dialing, proceeding, ringback), other paths are often possible. 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 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.