3.4.2 Outbound Calls in Asynchronous Mode

This section describes how calls are established and shows call scenarios for asynchronous outbound calls. The following topics describe the processing of outbound calls in asynchronous mode:

• Outbound Calls in Asynchronous Mode Overview
• Channel Initialization
• Call Dialing
• Call Proceeding
• Call Alerting
• Call Connected
• Overlap Sending
• Call Failure
• Outbound Call Scenarios in Asynchronous Mode

3.4.2.1 Outbound Calls in Asynchronous Mode Overview

Figure 10 illustrates a basic Outbound Call Model, which shows the call states associated with establishing a call in the asynchronous mode. All calls start from a Null state. The call establishment process for outbound calls is shown. Table 7 presents a summary of the outbound call state transitions.

Figure 10. Basic Asynchronous Outbound Call State Diagram

Table 7. Asynchronous Outbound Call State Transitions

State	Previous/Next State	Valid Call State Transition Functions	Call Transition Events
Alerting (GCST_ALERTING) Maskable	Previous: Proceeding, Dialing, SendMoreInfo Next: GCEV_CONNECTED -> Connected state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL GCEV_CONNECTED
Dialing (GCST_DIALING) Not Maskable	Previous: Null Next: GCEV_CONNECTED -> Connected state GCEV_ALERTING -> Alerting (Delivered) state GCEV_PROCEEDING -> Proceeding state GCEV_REQMOREINFO -> SendMoreInfo state GCEV_SENDMOREINFO -> SendMoreInfo state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_SendMoreInfo( ) gc_DropCall( )	GCEV_CONNECTED, GCEV_ALERTING, GCEV_REQMOREINFO, GCEV_PROCEEDING,GCEV_DISCONNECTED, GCEV_DROPCALL
Null (GCST_NULL) Not Maskable	Previous: Idle Next: gc_ResetLineDev( ) -> Null GCEV_DIALING -> Dialing state GCEV_DETECTED -> Detected state	gc_MakeCall( )	GCEV_DIALING
Proceeding (GCST_PROCEEDING) Maskable	Previous: Dialing, SendMoreInfo Next: GCEV_ALERTING -> Alerting (Delivered) state GCEV_CONNECTED -> Connected state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL ->Idle state	gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL, GCEV_CONNECTED, GCEV_ALERTING
SendMoreInfo (GCST_SENDMOREINFO) Maskable	Previous: Dialing Next: GCEV_CONNECTED -> Connected state GCEV_PROCEEDING -> Proceeding state. GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_SendMoreInfo( ) gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL, GCEV_PROCEEDING GCEV_CONNECTED

The following sections describe the asynchronous outbound call processes, as shown in Figure 10, "Basic Asynchronous Outbound Call State Diagram".

3.4.2.2 Channel Initialization

To establish calls, the following conditions must be met:

• The condition of the line device must be unblocked. When a channel is initially opened, the initial condition of a line device is blocked. A "blocking" condition on a line device is indicated by the reception of a GCEV_BLOCKED event and an "unblocking" condition on a line device is indicated by the reception of a GCEV_UNBLOCKED event. The GCEV_BLOCKED and GCEV_UNBLOCKED events are sent as unsolicited events to the application in response to blocking alarms. (For more information on blocking alarms and the GCEV_BLOCKED and GCEV_UNBLOCKED events, see Section 4.3, "Blocked and Unblocked Event Handling"). When the condition of the line device is unblocked, the line device is ready for establishing calls.
• The call state of the channel must be in the Null state. This is the initial call state of a line device when it is first opened. This state is also reached when a call is released or after the channel is reset by issuing the gc_ResetLineDev( ) function.

If the above conditions are met, the application is ready to make outbound calls.

3.4.2.3 Call Dialing

To initiate an outbound call using the asynchronous mode, the application issues a gc_MakeCall( ) function that requests an outgoing call to be made on a specific line device. The gc_MakeCall( ) function returns immediately. and the call state transitions to the Dialing state. The GCEV_DIALING event is generated (if enabled) to indicate that the call has transitioned to the Dialing state. A CRN is assigned to the call being established on that line device. If the gc_MakeCall( ) function fails, the line device remains in the Null state. In this state, dialing information is sent to the remote side.

3.4.2.4 Call Proceeding

In the Dialing state, the remote side may indicate that all the information was received and the call is proceeding. In this case, the GCEV_PROCEEDING event is generated and the call transitions to the Proceeding state. The remote side may either accept or answer the call.

3.4.2.5 Call Alerting

If the remote end is not ready to answer the call, a GCEV_ALERTING event is generated. This event indicates that the called party has accepted but not answered the call and that the network is waiting for the called party to complete the connection. At this stage, the remote side is typically ringing. This GCEV_ALERTING event changes the call state to the Alerting state.

3.4.2.6 Call Connected

When the called party immediately accepts the call, such as a call directed to a FAX or voice messaging system, a GCEV_CONNECTED event is generated to indicate that the connection was established. This event changes the call to the Connected state. In the Connected state, the call is connected to the called party and call charges begin.

When the call is answered (the remote end makes the connection), a GCEV_CONNECTED event changes the call to the Connected state. In the Connected state, the call is connected to the called party and call charges begin. The GCEV_CONNECTED event indicates successful completion of the gc_MakeCall( ) function.

3.4.2.7 Overlap Sending

In the Dialing state, if the remote side requests more information such as the destination address, the GCEV_REQMOREINFO event is generated and the call transitions to the SendMoreInfo state. The gc_SendMoreInfo( ) function is issued to send more information. If the remote side still requests more information, the GCEV_REQMOREINFO event is generated again. Once the remote side has received sufficient information, it indicates that the call is proceeding, and accepts or answers the call. Some technologies, such as SS7, do not have any messages or signals to request more information. For such protocols, the application never gets the unsolicited GCEV_REQMOREINFO event. In this case, the application may call the gc_SendMoreInfo( ) function to send more information as it becomes available.

3.4.2.8 Call Failure

The following are two causes of call failures:

Call Rejection

When the remote end does not answer the call, a GCEV_DISCONNECTED event is generated. This event is also generated when an inbound call arrives while the application is setting up an outbound call, causing a "glare" condition. Unless the protocol specifies otherwise, the incoming call takes precedence over the outbound call. When an asynchronous gc_MakeCall( ) function conflicts with the arrival of an inbound call, all the resources need to be released for the outbound call. Subsequently, the GCEV_DISCONNECTED event is generated with a result value indicating that an inbound call took precedence. The gc_DropCall( ) function must be issued after the GCEV_DISCONNECTED event is received.

If a gc_MakeCall( ) function is issued while the inbound call is being set up, the gc_MakeCall( ) function fails. The inbound call event is held in the driver until the CRN of the outbound call is released using the gc_ReleaseCallEx( ) function. After release of the outbound CRN, the pending inbound call event is sent to the application. This behavior may be modified by the individual protocol specification.

Task Failure

If the gc_MakeCall( ) cannot be completed successfully, a GCEV_TASKFAIL event or a GCEV_DISCONNECTED event is sent to the application. The result value associated with the event indicates the reason for the event. If the GCEV_TASKFAIL event is sent, then a problem occurred when placing the call from the local end.

3.4.2.9 Outbound Call Scenarios in Asynchronous Mode

This section shows various asynchronous outbound call scenarios. For call scenarios used for a specific signaling protocol, check the Global Call Technology User's Guide for that technology.

Figure 11 shows a basic asynchronous call scenario for outgoing calls.

Figure 11. Asynchronous Outbound Call Scenario

Figure 12 shows an asynchronous call scenario for outgoing calls with call acknowledgement.

Figure 12. Asynchronous Outbound Call Scenario With Call Acknowledgement

Figure 13 shows an asynchronous call scenario for outgoing calls with overlap sending.

Figure 13. Asynchronous Outbound Call Scenario With Overlap Sending

Click here to contact Telecom Support Resources