# Inbound call procedures

After you start a protocol on a line context with nccStartProtocol, the protocol is eligible to receive incoming calls. An inbound call is established in the following way:

Stage | Description
1 | The telephone network offers the call, and the call state changes to the seizure call state. NCC generates an NCCEVN_SEIZURE_DETECTED event indicating transition to the seizure call state, and assigns a call handle to the call, to be used for all future activity with this call. The application can retrieve the associated line handle (ctahd) by invoking nccGetCallStatus. If this is the first call on the line, the line state changes from idle to active.
2 | The network delivers the call to the NCC API, and the call state changes to incoming. NCC generates an NCCEVN_INCOMING_CALL event. Depending upon the setting of the NCC.START.overlappedreceiving parameter, the transition to the incoming call state may be preceded by an interval in which the network sends one or more digits (for example, caller ID). For more information, see Receiving overlapped digits.
3 | The application decides whether to answer or reject the call, using the nccAnswerCall or nccRejectCall functions. With some protocols, the application can accept a call immediately without answering or rejecting it, using the nccAcceptCall function. This action allows the application to perform media functions (such as playing a voice file) before connecting (or rejecting) the call. To help determine what to do with a call, the application can invoke nccGetCallStatus to retrieve the incoming address (caller ID) or other information. For more information, see Getting caller address information (caller ID).
4 | The NCC API performs network procedures to execute the application's decision, and returns appropriate events: If the application does not respond to the NCCEVN_INCOMING_CALL event, the call is rejected. If the application accepts the call, the NCC API generates NCCEVN_ACCEPTING_CALL. The event value field contains the acceptance method. The call state changes to accepting. From this state, the application can answer or reject the call. (This state may not be valid, depending upon the protocol.) If the application answers the call, the NCC API generates NCCEVN_ANSWERING_CALL. The call state changes to answering. If the application rejects the call, the NCC API generates NCCEVN_REJECTING_CALL. The call state changes to rejecting.
5 | If the call is successfully established, the NCC API generates NCCEVN_CALL_CONNECTED. The call state changes to connected.
6 | If the connection is unsuccessful, or the application rejects the call, the NCC API generates NCCEVN_CALL_DISCONNECTED. The call state changes to disconnected. The application can then release the call with nccReleaseCall.

## Inbound call sequence

The following illustration shows two protocol timing sequences: one for answering an inbound call, and one for rejecting an inbound call. The illustration shows the normal exchange of commands and events between the NCC API and the application. Optional events are shown with a dashed line:

## Inbound call sequence (including nccAcceptCall)

The following illustration shows the same sequences, except the application accepts the call before answering or rejecting it: