# State machine changes

The following changes were made to the call control state machine:

Change | Details
Line states and call states | Two separate call control state machines now exist, one for the line and one for the call on the line.
Inbound call state machine changes | New inbound call states were added: seizure, receiving digits.
Outbound call state machine changes | New outbound call states were added: outbound initiated, proceeding.
Disconnecting and releasing calls | The disconnected state is now a mandatory state that cannot be bypassed. Once a call enters the state machine, it must pass through the disconnected state before it is released. In addition, the idle state is now a line state, not a call state.

## Line states and call states

There are now two separate state machines, one for the line and one for each call on the line. States concerning the line are referred to as line states. States concerning a call on a line are referred to as call states.

A line can be in any of 5 separate line states: uninitialized, idle, blocking, out of service, or active. A line is in uninitialized line state until a protocol is started on the line. The line then enters idle line state. The line enters active line state when seizure is detected, or a call placement attempt is made (a call is initiated on the line). The line remains in active line state as long as the call is active. If a call is placed on hold, or is disconnected, it is no longer considered active. In this case, the line returns to idle state.

A call has no state until it is incoming, or is being placed. If inbound, the call can be in one of 6 to 8 states (the number of possible states depends upon the protocol). If outbound, the call can be in one of five states.

Once a call is released, it is destroyed. It no longer has a state.

Refer to NCC service call control model for more information about state machines.

## Inbound call state machine changes

The following table describes the changes to the inbound call state machine:

State | Description
Seizure | This state was added between the idle state (now a line state) and the incoming call state. This state is entered with an unsolicited NCCEVN_SEIZURE_DETECTED event (an informational event in ADI). Transition to this state indicates that a call is being set up (seized). Receipt of NCCEVN_INCOMING_CALL indicates that the call has changed to incoming call state.
Receiving digits | An optional state (not supported by some protocols). Entered from the seizure state with an unsolicited NCCEVN_RECEIVED_DIGIT. Indicates that a set of one or more incoming digits has been received, and the protocol has set itself up to handle digits in overlap receiving mode. When a call is in this state, the application can accept, answer, or reject the call at any time. The NCC.START.overlappedreceiving parameter controls whether or not you receive this event. Refer to NCC service global parameters for information about this parameter.
Accepting call | This state is now an optional state (not supported by some protocols).

## Outbound call state machine changes

The following states were added to the outbound call state machine:

State | Description
Outbound initiated | Entered by instantiating a call object using nccPlaceCall. No event indicates transition into this state. It signifies that a call has been initiated. When the line has been seized and the network has allowed the call to be placed by the NCC service (glare is resolved), the call moves into the placing call state. The application receives NCCEVN_PLACING_CALL.
Proceeding | A state between the placing call state and the connected state. NCCEVN_CALL_PROCEEDING indicates transition into this state. Signifies that the switch has accepted a call setup request and is in the process of attempting to alert the receiving end. Call progress analysis is begun.

## Disconnecting and releasing calls

An inbound call can no longer change from the answering call state or the connected state directly to the idle state. The call must pass through the disconnected state first, before being released. Once a call is released, it has no state.

An outbound call must also pass through the disconnected state, before being released. The only exception in this case is if the call cannot pass beyond the outbound initiated state, because a glare situation exists. In this case, the call is immediately released. NCCEVN_CALL_RELEASED is received by the application. The value field of this event is NCC_RELEASED_GLARE.

A call can become disconnected if:

- The application invokes nccDisconnectCall.

- The remote party hangs up. This can occur in almost any call state.

- The call is inbound, and the application rejects the call.

- (ADIMGR NCC implementation only) The call is outbound, the remote party has answered, and the call fails to meet the criteria specified by the NCC_X.ADI_PLACECALL_PARMS connectmask passed with nccPlaceCall, or meets the criteria specified by the disconnectmask.

- A call is successfully transferred using nccTransferCall or nccAutomaticTransfer (see Transferring calls).

When a call is disconnected, it enters the disconnected state. NCCEVN_CALL_DISCONNECTED is returned to the application. The application must then release it using nccReleaseCall. This function destroys the call handle and releases all resources attached to the call.

A disconnected call is no longer considered active. If there are no active calls on the line, the line returns to idle line state.

For more information about disconnecting and releasing calls, see Disconnecting calls.