Receiving Calls

After an application has opened a line device and, while doing so, registered a privilege other than none, and a media mode, it is notified when a call arrives on that line. Specifically, applications that have the line open with LINECALLPRIVILEGE_MONITOR will receive a LINE_CALLSTATE message for every call that arrives on the line. An application that has opened the line with LINECALLPRIVILEGE_OWNER receives a LINE_CALLSTATE message only if it has become an owner of the call or is the target of a directed handoff. In this notification, TAPI gives the application a handle to the incoming call, and the application keeps this handle until the application deallocates the call.

Note  To assist in object-oriented implementations of TAPI, in versions 2.0 and later TAPI initially sends a LINE_APPNEWCALL message (instead of a LINE_CALLSTATE message) to the application to notify it of a new call handle.

Applications are informed of call arrivals and all other call-state events with the LINE_CALLSTATE message. This message provides the call handle, the application's privilege to the call, and the call's new state. For an unanswered incoming call, the call state is offering. An application can invoke lineGetCallInfo to obtain information about an offering call before accepting it. This function call also causes the call information in the LINECALLINFO data structure to be updated. By knowing the call state and other information, the application can determine whether the call needs to be answered.

The call information stored in LINECALLINFO includes, among other things, the following items:

• Bearer mode, rate This is the bearer mode (voice, data) and data rate (in bits per second) of the call, for digital data calls.
• Media mode The current media mode of the call. Unknown is the mode specified if this information is unknown, and the other set bits indicate which media modes might possibly exist on the call. For more information, see Multiple-Application Programming.
• Call origin Indicates whether the call originated from an internal caller, an external caller, or an unknown caller.
• Reason for the call Describes why the call is occurring. Possible reasons are:
  • Direct call
  • Transferred from another number
  • Busy—forwarded from another number
  • Unconditionally forwarded from another number
  • The call was picked up from another number
  • A call completion request
  • A callback reminder

  The reason for the call is given as unknown if this information is not known.

• Caller-ID Parameter that identifies the originating party of a call. This can be in a variety of (name or number) formats, determined by what the switch or network provides.
• Called-ID Parameter that identifies the party originally dialed by the caller.
• Connected-ID Parameter that identifies the party to which the call was actually connected. This may be different from the called party if the call was diverted.
• Redirection-ID Parameter that identifies to the caller the number to which the call is now diverted (redirected).
• Redirecting-ID Parameter that identifies to the caller the original destination from which the call was diverted (redirected).
• User-user information User-user information sent by the remote station (ISDN).

The LINE_CALLSTATE message also notifies monitoring applications about the existence and state of outgoing (and incoming) calls established by other applications or established manually by the user—for example, on an attached phone device (if the telephony hardware and the service provider support monitoring of actions on external equipment). The call state of such calls reflects the actual state of the call as follows: An incoming call for which ownership is given to another application is indicated to the monitor applications as initially being in the offering state. An outgoing call placed by another application would normally first appear to the monitoring applications in the dialtone state.

The fact that a call is offered does not necessarily imply that the user is being alerted. Once alerting (ringing) has begun, a separate LINE_LINEDEVSTATE message is sent with a ringing indication to inform the application. It may be necessary, in some telephony environments, for the application to accept the call (with lineAccept) before ringing starts. The application can determine whether or not this is necessary by checking the LINEADDRCAPFLAGS_ACCEPTTOALERT bit.

Depending on the telephony environment, not all the information about a call may be available at the time the call is initially offered. For example, if caller ID is provided by the network between the first and second ring, caller ID will be unknown at the time the call is first offered. When it becomes known shortly thereafter, a LINE_CALLINFO message notifies the application about the change in party-ID information of the call.