After tapi32.dll opens a line device and calls TSPI_lineSetDefaultMediaDetection to specify the desired media modes for inbound calls, it can be notified when a call arrives. The service provider informs tapi32.dll of a new incoming call in the LINE_NEWCALL callback message. This message passes the service provider's handle for the call to tapi32.dll. The tapi32.dll returns its handle for the call. The service provider follows this with a LINE_CALLSTATE callback message. For an unanswered inbound call, the call state is offering. tapi32.dll can then invoke TSPI_lineGetCallInfo to find out information about the call. The fact that a call is offered may not necessarily imply that the user is being alerted. A separate LINE_LINEDEVSTATE callback is made with a ringing indication to provide this information to tapi32.dll.
LINE_NEWCALL can fail due to finite-resource limitations. The tapi32.dll may run out of resources to handle a new call under very high traffic conditions. In such a case, tapi32.dll returns NULL instead of a valid call handle, indicating that the newly offered call handle was not successfully received. The service provider can respond by dropping the call or by retrying the LINE_NEWCALL after a scheduling delay. In any case, the service provider must check for this NULL return and must never attempt to pass subsequent messages using the invalid call handle.
The LINE_NEWCALL message and subsequent LINE_CALLSTATE message also notifies tapi32.dll about the existence and state of outbound calls established as a side effect of other calls (for example, when an active call is put on hold and replaced by a new call in dial tone state) or manually by the user (for example, on an attached phone device). The call state of such calls reflects the actual state of the call, which will not be offering. By examining the call state, tapi32.dll can determine whether the call is an inbound call that needs to be answered.
Call information includes (among other things):
Depending on the telephony environment, not all information about a call may be available at the time the call is initially offered. For example, if caller identifier is provided by the network between the first and second ring, the caller identifier is still unknown when the call is first offered. When it becomes known shortly thereafter, a LINE_CALLINFO callback message notifies tapi32.dll about the change in party-identifier information of the call.
If a new call arrives while another call already exists on the line or address, similar notification and call information is supplied following the same mechanism as for any incoming call. If an application does not want any interference for a call from the switch or phone network, it should secure the call. Securing a call can be done at the time the call is made using a parameter of TSPI_lineMakeCall, or later, with the function TSPI_lineSecureCall, when the call already exists. The call is secured from interference by other events until it is disconnected. Securing a call may be useful, for example, when it is feared that certain network tones (such as call waiting) could disrupt a call's media stream, such as fax.
After tapi32.dll is offered a call, it can answer the call using TSPI_lineAnswer. After a call is answered, its state typically transitions to connected and information can be exchanged over it.