3.5.2 Outbound Calls in Synchronous Mode

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

• Outbound Calls in Synchronous Mode Overview
• Channel Initialization
• Call Dialing
• Call Proceeding
• Call Alerting
• Call Connected
• Outbound Call Scenario in Synchronous Mode

3.5.2.1 Outbound Calls in Synchronous Mode Overview

Figure 21 shows the outbound synchronous call model states. Table 10 shows a summary of call state transitions.

The overlap sending/receiving feature is not supported in the outbound synchronous call model. Typically, synchronous calls are made when the application does not need the intermediate function calls or events for establishing a call. However, the overlap feature requires intermediate state transitions where additional function calls need to be made. In addition, synchronous functions always return upon successful completion. But in the overlap mode, functions must return before successful completion due to an intermediate request for more information. Handling all the possible cases complicates the synchronous model.

Figure 21. Outbound Synchronous Call Process

Table 10. Synchronous 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: gc_DropCall( ) -> Idle state	gc_DropCall( )	GCEV_DISCONNECTED
Dialing (GCST_DIALING) Maskable	Previous: Null Next: gc_DropCall( ) -> Idle state	gc_DropCall( )	GCEV_ALERTING, GCEV_DISCONNECTED
Null (GCST_NULL) Not Maskable	Previous: Idle Next: gc_MakeCall( ) -> Dialing state gcDropCall( ) -> Idle state	gc_MakeCall( )
Proceeding (GCST_PROCEEDING) Not Maskable	Previous: Dialing, SendMoreInfo Next: gc_DropCall( ) -> Idle state	gc_DropCall( )	GCEV_DISCONNECTED, GCEV_ALERTING

3.5.2.2 Channel Initialization

In order 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 gc_ResetLineDev( ).

If the above conditions are met, the application is ready to receive inbound calls.

3.5.2.3 Call Dialing

To initiate an outbound call (see Figure 21 and Table 10) using the synchronous mode, the application issues the gc_MakeCall( ) function, which requests an outgoing call to be made on a specific line device. A CRN is assigned to the call being made on the specific line device. Dialing information is then sent to and acknowledged by the network. When the gc_MakeCall( ) function is issued in the synchronous mode, the function returns successfully when the call reaches the Connected state. See the Global Call Technology User's Guide for your technology for valid completion points for the gc_MakeCall( ) function.

Some call related events indicating the status of the call may be generated, if enabled, while the gc_MakeCall( ) function is in progress.

3.5.2.4 Call Proceeding

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

3.5.2.5 Call Alerting

If the remote end is not ready to answer the call, the GCEV_ALERTING event is generated, if enabled. 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.5.2.6 Call Connected

When the call is answered (the remote end makes the connection), the gc_MakeCall( ) function completes successfully and the call changes to the Connected state.

3.5.2.7 Outbound Call Scenario in Synchronous Mode

Figure 22 shows a synchronous outbound call scenario. For call scenarios used for a specific signaling protocol, check the Global Call Technology User's Guide for that technology.

Figure 22. Outbound Call Scenario in Synchronous Mode

Click here to contact Telecom Support Resources