(Page 1 of 1 in this chapter)

Chapter 4

Call Control (ACU Configuration)

4.1 Introduction
4.1.1 About Connection Ids
4.2 The ISDN Call Control State Machine
4.3 Receiving Inbound Calls
4.3.1 Accepting the Call
4.3.2 Rejecting the Call
4.3.3 Incoming Calls With Overlap Receiving Mode Enabled
4.4 Placing Outbound Calls
4.5 Call Collision
4.6 Call Clearing
4.6.1 Clear Collision

4.1 Introduction

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.3.4 for a detailed discussion of the state machine implemented by the AG ISDN demonstration program.

4.1.1 About Connection Ids

The connection id is a handle to a call on a B channel. It is used to identify the call in all communications between the ACU and the application. When an incoming call arrives, the protocol stack assigns it a connection id. When the application places a call, it assigns a connection id to the call. When a call is disconnected, the connection id is freed. The id can then be assigned to a new call by the protocol stack or the application.

A different set of connection ids is available for each D channel. Thus a call is identified both by its D channel context and by its connection id.

The range of connection ids available for a trunk is between 0 and ACU_MX_CALLS (defined in isdnacu.h). In an NFAS group containing multiple trunks, there will be ACU_MX_CALLS connection ids for each NAI. The connection id and NAI together identify a particular call.

The connection id assigned to an incoming call by the protocol stack is the highest available unused value. For example, if 60 connection ids are available for a trunk, and connection ids 59 and 58 are already allocated to calls, the protocol stack assigns id 57 to the next call.

To avoid any chance of collision, when placing outgoing calls, the application should assign connection ids beginning with 0. The application must keep track of which connection ids are in use and which are available. (The demonstration program documented in Chapter 9 illustrates this.)

4.2 The ISDN Call Control State Machine

Figure 19 illustrates the AG ISDN call control state machine:

Figure 19. AG ISDN Call Control State Machine





4.3	 Receiving Inbound Calls





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.






4.3.1	 Accepting the Call





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 20 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.






Figure 20.	 Message Sequence - Accepted Incoming Call






4.3.2	 Rejecting the 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 21 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.






Figure 21.	 Message Sequence - Rejected Inbound Call






4.3.3	 Incoming Calls With Overlap Receiving Mode Enabled





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 substructure is referenced in the ISDN_PROTOCOL_ PARMS structure passed to isdnStartProtocol.) For more information, see Appendix C.






4.4	 Placing Outbound Calls





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_CALL_PROC_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.


Figure 22 illustrates the sequence of messages sent between the ACU and the application for an accepted outbound call:






Figure 22.	 Message Sequence - Accepted Outbound Call










4.5	 Call Collision





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. In this case, the terminal side must cancel its outgoing call, and accept the incoming call.



Call collision can take place at the stack or at the network level. Call collision at the stack occurs when a SETUP message is received by the stack directly before it receives an ACU_CONN_RQ from the application. Figure 23 illustrates the sequence of messages sent between the ACU and the application in this situation:






Figure 23.	 Message Sequence - Call Collision at Stack Level




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.



Call collision at the network level occurs when the stack sends a SETUP message to the trunk directly before receiving a SETUP message from the trunk. If the stack is configured as terminal equipment, it abandons its call setup attempt and receives the incoming call. Figure 24 illustrates the sequence of messages exchanged in this situation:






Figure 24.	 Message Sequence--Call Collision at Network Level, Terminal Side




If the stack is configured as network equipment, it continues with its call setup attempt, signaling the trunk to release the incoming call. Figure 25 illustrates the sequence of messages exchanged in this situation.






Figure 25.	 Message Sequence--Call Collision at Network Level, Network Side




In any situation, if the application sends an ACU primitive to the stack while the stack is sending ACU_CLEAR_CO, the stack re-sends ACU_CLEAR_CO. In this case, the application receives two ACU_CLEAR_CO primitives.






4.6	 Call Clearing





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 26 illustrates the sequence of messages sent between the ACU and the application when the application initiates a hang up:






Figure 26.	 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 27 illustrates the sequence of messages sent between the ACU and the application when a hang up is received by the application.






Figure 27.	 Message Sequence - Incoming Clearing






4.6.1	 Clear Collision





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. 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).



Clear collision can take place at the stack level or at the network level. Clear collision at the stack level takes place when a DISCONNECT message is received by the stack directly before it receives an ACU_CLEAR_RQ from the application. Figure 28 illustrates the sequence of messages exchanged in this situation:






Figure 28.	 Message Sequence - Clear Collision at Stack Level




Clear collision at the network level takes place when a DISCONNECT message is received by the network directly after it sends a DISCONNECT message to the stack. Figure 29 illustrates the sequence of messages exchanged in this situation:






Figure 29.	 Message Sequence--Clear Collision at Network Level








 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.