3.5.1 Inbound Calls in Synchronous Mode

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

• Inbound Calls in Synchronous Mode Overview
• Channel Initialization
• Call Offered
• Call Routing
• Call Acceptance
• Call Establishment
• Overlap Receiving
• Call Failure
• Inbound Call Scenarios in Synchronous Mode

3.5.1.1 Inbound Calls in Synchronous Mode Overview

Figure 17 illustrates a Basic Call Model, and indicates the call states associated with establishing or setting up a call in the synchronous mode. The call establishment process for inbound calls is shown. All calls start from a Null state. See Table 9 for a summary of the call state transitions.

Some features, such as overlap sending/receiving, are not supported in the synchronous mode. Typically, synchronous calls are made when the application does not care about the intermediate function calls or events required for establishing a call. However, the overlap feature requires intermediate state transitions where additional function calls need to be made. Previously, functions returned upon successful completion, but in the overlap mode they may return before successful completion, possibly due to an intermediate request for more information.

Note: The Advanced Call Model includes call states associated with holding, retrieving and transferring calls. See Section 3.6, "Advanced Call Control with Call Hold and Transfer" for more information.

Figure 17. Basic Synchronous Inbound Call State Diagram

Table 9. Synchronous Inbound Call State Transitions

State Description	Previous/Next State	Valid Call State Transition Functions	Call Transition Events
Accepted (GCST_ACCEPTED) Maskable	Previous: Offered, GetMoreInfo, CallRouting Next: gc_AnswerCall( ) -> Connected state. GCEV_DISCONNECTED -> Disconnected state gc_DropCall( ) -> Idle state	gc_AnswerCall( ), gc_DropCall( )	GCEV_DISCONNECTED
Call Routing (GCST_CALLROUTING) Maskable	Previous: Offered, GetMoreInfo Next: gc_AnswerCall( ) -> Connected state gc_AcceptCall( ) -> Accepted state GCEV_DISCONNECTED -> Disconnected state gc_DropCall( ) -> Idle state	gc_AnswerCall( ), gc_AcceptCall( ), gc_DropCall( )	GCEV_DISCONNECTED
Connected (GCST_CONNECTED) Not Maskable	Previous: Accept, Offered, GetMoreInfo, CallRouting, Dialing, SendMoreInfo, Proceeding, Alerting Next: GCEV_DISCONNECTED -> Disconnected state gc_DropCall( ) -> Idle state	gc_DropCall( )	GCEV_DISCONNECTED
GetMoreInfo (GCST_GETMOREINFO) Maskable	Previous: Offered Next: gc_AnswerCall( ) -> Connected state gc_AcceptCall( ) -> Accepted state gc_CallAck( ) sends CallProceeding -> CallRouting state gc_ReqMoreInfo( ) -> GetMoreInfo state GCEV_DISCONNECTED -> Disconnected state gc_DropCall( ) -> Idle state	gc_ReqMoreInfo( ), gc_CallAck( ), gc_AnswerCall( ), gc_AcceptCall( ), gc_DropCall( )	GCEV_DISCONNECTED
Null (GCST_NULL) Not Maskable	Previous: Idle Next: gc_WaitCall( ) -> Offered state	gc_WaitCall( )	GCEV_DETECTED
Offered (GCST_OFFERED) Not Maskable	Previous: Null, Detected Next: gc_AnswerCall( ) -> Connected state gc_AcceptCall( ) ->Accepted state gc_CallAck( ) sends CallProceeding -> CallRouting state gc_CallAck( ) requests more info -> GetMoreInfo state GCEV_DISCONNECTED -> Disconnected state gc_DropCall( ) -> Idle state	gc_CallAck( ), gc_AnswerCall( ), gc_AcceptCall( ), gc_DropCall( )	GCEV_DISCONNECTED

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

If the above conditions are met, the application must issue a gc_WaitCall( ) function in the Null state to indicate readiness to accept an inbound call request on the specified line device. In the synchronous mode, the gc_WaitCall( ) function waits for an inbound call for the length of time specified by the timeout parameter. When the timeout expires, the function fails with an error code, EGC_TIMEOUT, and must be reissued. If the time specified is 0, the function fails unless a call is already pending on the specified line device.

A gc_WaitCall( ) function waiting for a call to arrive can be stopped (terminated) by issuing the gc_ResetLineDev( ) function. When the gc_WaitCall( ) function fails or is stopped, all system resources including the CRN assigned to the call are released. To accept inbound calls, another gc_WaitCall( ) function must be issued each time the application wishes to receive an inbound call. The application blocks to wait for an incoming call by issuing the gc_WaitCall( ) function. The application must repeat the poll for incoming calls by issuing the gc_WaitCall( ) function each time it polls for a call.

3.5.1.3 Call Offered

The inbound call from the network is received on the specified line device but is not yet offered to the application, which causes the call state to change to the Detected state, if supported. At this stage, the call is being processed, which typically involves allocating resources or waiting for more information. If the call does change to the Detected state, no GCEV_DETECTED event is generated and the gc_WaitCall( ) function does not return until the call is offered to the application. After all the required processing is done, the call is offered to the application and the call state changes to the Offered state. The application may selectively retrieve call information, such as Destination address and Origination address (caller ID). If more information is required (overlap receiving) or the call needs to be acknowledged, the gc_CallAck( ) function must be issued. (See Section 3.5.1.7, "Overlap Receiving".) Otherwise the user can accept or answer the call by issuing the gc_AcceptCall( ) or gc_AnswerCall( ) respectively.

3.5.1.4 Call Routing

After the call has been offered, the gc_CallAck(GCACK_SERVICE_PROC) function can be issued to indicate to the other side that all the information has been received and the call is now proceeding. This stage typically involves routing the call to the destination exchange or party. An information call routing tone can be played at this point to inform the remote party that the call is routing.

3.5.1.5 Call Acceptance

If the application is not ready to answer the call, a gc_AcceptCall( ) function is issued to indicate to the remote end that the call was received but not yet answered. This provides an interval during which the system can verify parameters, determine routing, and perform other tasks before connecting the call. When the gc_AcceptCall( ) function is successfully completed, the call changes to the Accepted state. The application may selectively retrieve call information, such as the Destination address and Origination address (caller ID). The application can then answer the call by issuing the gc_AnswerCall( ) function.

3.5.1.6 Call Establishment

When the call is to be directly connected, such as to a voice messaging system, the gc_AnswerCall( ) function is issued to make the final connection. When the gc_AnswerCall( ) function is successfully completed, the call changes to the Connected state. At this time, the call is connected to the called party and call charges begin.

3.5.1.7 Overlap Receiving

After an incoming call has been received, the call is offered to the application based on the call acknowledgement configuration and the availability of information required for proceeding with the call. If the incoming call is in en-bloc mode where all the information required for processing the call is present, the call is offered to the application. Otherwise, the call is offered to the application based on the following:

Call Acknowledgement

If the application is configured to send the call acknowledgement, the call is immediately offered to the application regardless of the amount of information available. The application can then request and collect more information as required. If the technology call control layer is configured to send the call acknowledgement, then the call is offered to the application based on the minimum amount of information specified.

Minimum Information Specified

If the incoming call does not have sufficient information, the call is offered to the application based on the amount of information required. If the technology is configured to accept minimum information, the call is offered to the application only after the specified minimum amount of information is received. Thereafter, the application can request and collect more information as required. If the technology is not configured to accept minimum information, then the call is offered to the application regardless of the amount of information available. The application can then request and collect more information as required.

The following sections describe various configurations operating in overlap receiving mode.

Scenario 1

In this scenario, the application is configured to acknowledge the incoming call and send a call proceeding indication after sufficient information has been received. When an incoming call is detected, the call is immediately offered to the application regardless of the amount of information available to proceed with the call.

When the call is in the Offered state, the application sends an acknowledgement for the incoming call by issuing a gc_CallAck(GCACK_SERVICE_INFO). The application may selectively retrieve call information, such as Destination address and Origination address (caller ID) by issuing gc_GetCallInfo( ). If more information is still required, the gc_ReqMoreInfo( ) function is issued to request more information. The function returns when the requested information is received. The application may then send a call proceeding indication to the remote side by issuing the gc_CallAck(GCACK_SERVICE_PROC) function. Otherwise, the application can choose to accept or answer the call.

Scenario 2

In this scenario, the technology call control layer is configured to acknowledge the incoming call and send a call proceeding indication after sufficient information has been received. When an incoming call is detected, the technology call control layer immediately sends an acknowledgement.

If the minimum amount of information required is specified, then the call is offered to the application only after the minimum amount of information required is received. When the call is offered to the application and more information is required, the gc_CallAck(GCACK_SERVICE_INFO) must be issued. Since an acknowledgement was already sent out, no acknowledgement is sent to the remote side at this time. However, if the minimum amount of information is not specified, then the technology control layer requests and collects more information. After all the information is received, the technology control layer sends a call proceeding indication to the remote side. The call is then offered to the application, which can then accept or answer the call.

Scenario 3

In this scenario, the technology call control layer is configured to acknowledge the incoming call and the application is configured to send a call proceeding indication after sufficient information has been received. When an incoming call is detected, the technology call control layer immediately sends an acknowledgement.

If the minimum amount of information required is specified, then the call is offered to the application only after the minimum amount of information required is received. Otherwise the call is immediately offered to the application.

When the call is in the Offered state, the application may selectively retrieve call information, such as Destination address and Origination address (caller ID) by issuing the gc_GetCallInfo( ) function. If more information is required, the application may also request more address information using the gc_CallAck(GCACK_SERVICE_INFO) function. This function returns when the requested information is received. If more information is still required, the gc_ReqMoreInfo( ) function is issued to request more information. When all the required information is received, the application may send a call proceeding indication to the remote side by issuing the gc_CallAck(GCACK_SERVICE_PROC) function. Otherwise, the application can choose to accept or answer the call.

Scenario 4

In this scenario, the application is configured to acknowledge the incoming call and the technology call control layer is configured to send a call proceeding indication after sufficient information has been received. When an incoming call is detected, the call is offered to the application regardless of the amount of information available.

When the call is in the Offered state (after generation of the unsolicited GCEV_OFFERED event), the application sends an acknowledgement for the incoming call by issuing a gc_CallAck(GCACK_SERVICE_INFO). The application may selectively retrieve call information, such as the Destination address and Origination address (caller ID), by issuing the gc_GetCallInfo( ) function. If more information is still required, the gc_ReqMoreInfo( ) function is issued to request more information. This function returns when the requested information is received. When all the required information is received, the technology call control layer sends a call proceeding indication to the remote side. The application may also attempt to send a call proceeding indication to the remote side in case the technology call control layer hasn't done so. The application can then choose to accept or answer the call.

3.5.1.8 Call Failure

The following are various causes of call failures:

Call Rejection

From the Offered state, the application may reject the call by issuing the gc_DropCall( ) function followed by the gc_ReleaseCallEx( ) function. See Figure 17.

Forced Release

From the Accepted state, not all E-1 CAS protocols support a forced release of the line; that is, issuing the gc_DropCall( ) function after the gc_AcceptCall( ) function. If a forced release is attempted, the function fails, and an error is returned. To recover, the application should issue the gc_AnswerCall( ) function followed by the gc_DropCall( ) and gc_ReleaseCallEx( ) functions. However, anytime a GCEV_DISCONNECTED event is received in the Accepted state, the gc_DropCall( ) function can be issued.

Task Failure

If a call fails at any point in the call establishment process, the call stays in its current state. In most cases, the application needs to drop and release the call to return the line device to the Null state. However, in some cases, such as call failure due to a trunk error, the application needs to use the gc_ResetLineDev( ) function to reset the line device to the Null state. For more information, see the gc_DropCall( ), gc_ReleaseCallEx( ), and gc_ResetLineDev( ) function descriptions in the Global Call API Library Reference.

3.5.1.9 Inbound Call Scenarios in Synchronous Mode

The following shows the various synchronous inbound call scenarios. For call scenarios used for a specific signaling protocol, check the Global Call Technology User's Guide for that technology.

Figure 18 shows a basic synchronous call scenario for an incoming call.

Figure 18. Synchronous Inbound Call Scenario

Figure 19 shows a basic synchronous call scenario for an incoming call with call acknowledgement.

Figure 19. Synchronous Inbound Call Scenario With Call Acknowledgement

Figure 20 shows a basic synchronous call scenario for an incoming call with overlap receiving.

Figure 20. Synchronous Inbound Call Scenario With Overlap Receiving

Click here to contact Telecom Support Resources