This chapter describes the AG ISDN call control state machine. The chapter also describes the communications between the application and the ACU during call acceptance, rejection, collision and clearing.
Note: Refer to Section 9.5.1 for a detailed discussion of the state machine implemented by the AG ISDN demonstration program.
Figure 12 illustrates the AG ISDN call control state machine:
Figure 12: AG ISDN Call Control State Machine
ISDN events are generated by the ISDN protocol stack running on the AG board. When an ISDN event occurs, the event ID ISDNEVN_RCV_MESSAGE is returned in the ADI_EVENT or CTA_EVENT structure. When decoding the message, the following information is extracted:
When a call SETUP message is detected on the trunk, an ACU_CONN_IN is sent to the application from sender ENT_CC. Receipt of ACU_CONN_IN triggers a state transition from the NULL state to the state WAIT_INCOMING.
The application decodes the message and obtains the calling number and called number. The application program then decides to accept or reject the call based on the value of the called number.
To accept the call, the application builds a connect response message (ACU_CONN_RS) and sends it to the ISDN protocol stack. The event ACU_CONN_CO confirms that the call has been established. The stack switches to its ACTIVE state, where the application processing takes place.
Note: For applications in which the DSP resource is not connected to a B channel, a connection should be made when a connection indication occurs.
Figure 13 illustrates the default sequence of messages sent between the ACU and the application for an accepted inbound call. Note that the actual messages sent back and forth in response to an incoming call may differ from this example depending upon the settings of the bits in the in_calls_behavior sub-structure. (This sub-structure is referenced in the ISDN_PROTOCOL_PARMS structure passed to isdnStartProtocol). For details, see Appendix C: Parameters.
Figure 13: Message Sequence - Accepted Incoming Call
To reject the call, the application builds a clear request message (ACU_CLEAR_RQ) and sends it to the protocol stack. When the call is released, the network responds with ACU_CLEAR_CO.
Figure 14 illustrates the default sequence of messages sent between the ACU and the application for a rejected inbound call. Note that the actual messages may differ depending upon the settings of the bits in in_calls_behavior. (This sub-structure is referenced in the ISDN_PROTOCOL_PARMS structure passed to isdnStartProtocol). For details, see Appendix C: Parameters.
Figure 14: Message Sequence - Rejected Inbound Call
If overlap receiving mode is enabled, when a call arrives, the ACU sends ACU_CONN_IN to the application even if the called and/or calling number are not complete. The ACU then sends any additional incoming digits in ACU_DIGIT_IN messages.
To enable this mode, set the CC_TRANSPARENT_OVERLAP_RCV bit in in_calls_ behavior. (This sub-structure is referenced in the ISDN_PROTOCOL_ PARMS structure passed to isdnStartProtocol.) For more information, see Appendix C: Parameters.
The application initiates an outbound call by sending an ACU_CONN_RQ to the protocol stack. The connection id is assigned by the user. This id must not currently be in use; otherwise the connection request will be rejected by the ISDN protocol stack.
ACU_CONN_RQ must contain the complete called number.
At this point, an ACU_PROGRESS_IN event or an ACU_ALERT_IN event may be received from the network. These messages indicate that the call is progressing. If the call is successfully connected, the event ACU_CONN_CO is received. Otherwise a hang up indication, ACU_CLEAR_CO, is received.
Note: The bits in out_calls_behavior (in the ISDN_PROTOCOL_PARMS structure passed to isdnStartProtocol) control stack behavior with outgoing calls. For more information, see Appendix C: Parameters.
Figure 15 illustrates the sequence of messages sent between the ACU and the application for an accepted outbound call.
Figure 15: Message Sequence - Accepted Outbound Call
Call collision (i.e., glare) may occur when a call setup request and an incoming call occur on the same B channel at the same time between the application and network. In this case, the application must cancel its outgoing call, and accept the incoming call.
Figure 16 illustrates the sequence of messages sent between the ACU and the application when two calls collide.
Figure 16: Message Sequence - Call Collision
The ACU_CLEAR_IN is relative to the ACU_CONN_RQ sent by the application. The return_code field in the primitive's message data is set to ACURC_INCOMING, meaning that the outgoing call is cleared due to a call collision. No answer is sent by the application in response to this ACU_CLEAR_IN message.
To hang up, the application builds an ACU_CLEAR_RQ message with the connection ID of the associated call. Receipt of an ACU_CLEAR_CO confirms that the remote end has hung up. The stack returns to its IDLE state.
Figure 17 illustrates the sequence of messages sent between the ACU and the application when the application initiates a hang up.
Figure 17: Message Sequence - Outgoing Clearing
If the remote end hangs up first, the application receives an ACU_CLEAR_IN message. The application responds with an ACU_CLEAR_RS (clearing response). When the application receives ACU_CLEAR_CO, the clearing is confirmed. The stack returns to its IDLE state.
Figure 18 illustrates the sequence of messages sent between the ACU and the application when a hang up is received by the application.
Figure 18: Message Sequence - Incoming Clearing
Clear collision may occur when a call clearing request (ACU_CLEAR_RQ) and a call clearing indication (ACU_CLEAR_IN) for the same call are sent at the same time between the application and the ACU. In this case, the application must ignore the ACU_CLEAR_IN, and continue the call clearing as a normal outgoing call clearing (one issued by the application).
Figure 19 illustrates the sequence of messages sent between the ACU and the application when clear collision occurs.
Figure 19: Message Sequence - Clear Collision
Natural MicroSystems, Inc.
100 Crossing Boulevard
Framingham, MA 01702