3.3. ISDN Call Control States

• 3.3.1. Asynchronous Call Establishment
• 3.3.2. Synchronous Call Establishment
• 3.3.3. Asynchronous Call Termination
• 3.3.4. Synchronous Call Termination

Each ISDN call that is received or generated by an application is processed through a series of call control states. Each state represents the completion of certain tasks and/or the current status of the call. The following table describes the ISDN call control states, based on standard Q.931 (Layer 3).

Table 2. Call Control States

Call State	Description
Accepted	An indication to the network that the incoming call has been accepted, but has not been connected to the end user. (Most voice applications do not need this.)
Alerting	The destination is reached and the phone is ringing. This state may be reported to the application or masked depending on the application directive.
Connected	An incoming or outgoing call is established. Typically, billing begins at this point and the B channel is cut through.
Dialing	Address and call setup information has been sent to, and acknowledged by, the network. Call establishment is in progress.
Disconnected	The network terminates the call and the application should drop the call.
Idle	A call is dropped and waiting for the application to release the call reference number (CRN).
Null	No call is assigned to the device (time slot or line).
Offered	An incoming call is offered by the network.

The call states change according to the sequence of functions called by the application and the events that originate in the network and system hardware. The current state of a call can be changed by:

• function call returns
• termination events (indicate completion of a function)
• unsolicited events

The way calls transition between states differs depending on whether the application uses asynchronous or synchronous programming:

• In general, in asynchronous mode, events trigger the transitions between call states. For example, the termination event, CCEV_ANSWERED, causes the call state to change to the Connected state. Likewise, the unsolicited event, CCEV_DISCONNECTED, causes the call state to change to the Disconnected state.
• Synchronous functions return at the successful completion of the function or if the function fails. The function waits for a completion or failure message from the firmware before it terminates, and the call transitions to another call state. For example, the cc_MakeCall( ) and cc_ReleaseCall( ) functions cause the call state to change upon their successful return. (Note that synchronous functions return information, not events.)

The following sections describe the state transitions for both asynchronous and synchronous call processes. (Refer to the Voice Software Reference - Programmer's Guide for the appropriate operating system for details on the supported programming models.)

3.3.1. Asynchronous Call Establishment

Figure 3 illustrates the call states associated with establishing or setting up a call in the asynchronous mode. The call establishment process for outbound calls is shown on the right side of the diagram; the inbound call set up process is shown on the left. All calls start from a Null state. See Table 2 for descriptions of the call states.

Figure 3.  Asynchronous Call Establishment Process

Table 3 provides an example of a simple inbound call using the asynchronous call establishment process. The items denoted by an asterisk (*) are optional functions/events or maskable events that may be reported to the application. For more detailed call scenarios see Appendix A.

Table 3.  Inbound Call Set-Up (Asynchronous Example)

Function/Event	Action/Description
cc_WaitCall( )	Issued once after line device opened with cc_Open( ).
CCEV_OFFERED	Indicates arrival of inbound call and initiates transition to Offered state
*cc_GetANI( )	Request caller ID information
*cc_GetDNIS( )	Retrieves DNIS digits received from the network
*cc_CallAck( )	Requests additional call setup information
*cc_AcceptCall( )	Issued to acknowledge that call was received but called party has not answered.
*CCEV_ACCEPT	Termination event - indicates call received, but not yet answered; causes transition to Accepted state.
cc_AnswerCall( )	Issued to connect call to called party (answer inbound call).
CCEV_ANSWERED	Termination event - inbound call connected; causes transition to Connected state.
* = Optional functions and events or maskable events

Table 4 illustrates a simple scenario for making an outbound call using the asynchronous call establishment process. The items denoted by an asterisk (*) are optional functions/events or maskable events that may be reported to the application. For more detailed call scenarios, see Appendix A.

Table 4.  Outbound Call Set-up (Asynchronous Example)

Function/Event	Action/Description
cc_MakeCall( )	Requests a connection using a specified line device. A CRN is assigned and returned immediately; call is transitioned to the Dialing state. CCEV_CONNECTED event sent if call is connected; otherwise a CCEV_TASKFAIL event is sent.
*cc_SetEvtMsk( )	Specifies the events enabled or disabled for a specified line device.
*CCEV_ALERTING	Remote end was reached but a connection has not been established. When the call is answered, a CCEV_CONNECTED event is sent.
CCEV_CONNECTED	Indicates successful completion of cc_MakeCall( ). Call is in the Connected state.
* = Optional functions and events or maskable events

3.3.2. Synchronous Call Establishment

Figure 4 illustrates the call states associated with establishing or setting up a call in the synchronous mode. The call establishment process for outbound calls is shown on the right side of the diagram; the inbound call set up process is shown on the left. All calls start from a Null state. See Table 2 for descriptions of the call states.

Figure 4.  Synchronous Call Establishment Process

Table 5 provides an example of a simple inbound call using the synchronous call establishment process. The items denoted by an asterisk (*) are optional functions/events or maskable events that may be reported to the application. For more detailed call scenarios, see Appendix A.

Table 5.  Inbound Call Set-Up (Synchronous Example)

Function	Action/Description
cc_WaitCall( )	Enables notification of an incoming call after line device opened with cc_Open( ). Call is in OFFERED state.
*cc_GetANI( )	Request ANI information
*cc_GetDNIS( )	Retrieves DNIS digits received from the network.
*cc_CallAck( )	Requests additional call setup information
*cc_AcceptCall( )	Issued to acknowledge that call was received but called party has not answered. Call is in Accepted state.
cc_AnswerCall( )	Issued to connect call to called party (answer inbound call). At the successful completion of cc_AnswerCall( ), the call is in Connected state.
NOTES: 1. * = Optional functions 2. There are no termination events in synchronous mode.

Table 6 illustrates a simple scenario for making an outbound call using the synchronous call establishment process. The item denoted by an asterisk (*) is a maskable event that may be reported to the application. For more detailed call scenarios, see Appendix A.

Table 6.  Outbound Call Set-up (Synchronous Example)

Function/Event	Action/Description
cc_MakeCall( )	Requests a connection using a specified line device; a CRN is assigned and returned immediately.
*CCEV_ALERTING	Remote end was reached but a connection has not been established
none	When the cc_MakeCall( ) function successfully completes, the call is in the Connected state.
NOTES: 1. * = Maskable events 2. There are no termination events in synchronous mode.

3.3.3. Asynchronous Call Termination

Figure 5 illustrates the call states associated with call termination or call teardown in the asynchronous mode initiated by either call disconnection or failure. A call can be terminated by the application or by the detection of call disconnect from the network. Either of these terminations can occur at any point in the process of setting up a call and during any call state. See Table 2 for descriptions of the call states.

Figure 5.  Asynchronous Call Disconnect or Failure Process

Table 7 presents an asynchronous call termination scenario. The item denoted by an asterisk (*) is an optional function call. For more detailed call scenarios, see Appendix A.

Table 7.  Call Termination (Asynchronous Example)

Function/Event	Action/Description
CCEV_DISCONNECTED	Unsolicited event generated when call is terminated by network; initiates transition to Disconnected state.
cc_DropCall( )	Disconnects call specified by CRN. CCEV_DROPCALL event indicates completion of function
CCEV_DROPCALL	Termination event - call disconnected and changes to Idle state
*cc_GetBilling( )	Retrieves billing information
cc_ReleaseCall( ) cc_ReleaseCallEx( )	Issued to release all resources used for call; network port is ready to receive next call. Causes transition to Null state.
* = Optional functions

3.3.4. Synchronous Call Termination

Figure 6 illustrates the call states associated with call termination or call teardown in the synchronous mode initiated by either call disconnection or failure. A call can be terminated by the application or by the detection of call disconnect from the network. Either of these terminations can occur at any point in the process of setting up a call and during any call state. See Table 2 for descriptions of the call states.

Figure 6.  Synchronous Call Disconnect or Failure Process

Table 8 presents a synchronous call termination scenario. The item denoted by an asterisk (*) is an optional function call. For more detailed call scenarios, see Appendix A.

Table 8.  Call Termination (Synchronous Example)

Function/Event	Action/Description
CCEV_DISCONNECTED	Unsolicited event generated when call is terminated by network; initiates transition to Disconnected state.
cc_DropCall( )	Disconnects call specified by CRN. Initiates transition to Idle state.
*cc_GetBilling( )	Retrieves billing information
cc_ReleaseCall( )	Issued to release all resources used for call; network port is ready to receive next call. Causes transition to Null state.
NOTES: 1. * = Optional function 2. There are no termination events in synchronous mode.

Click here to contact Dialogic Customer Engineering