3.4.1 Inbound Calls in Asynchronous Mode

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

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

3.4.1.1 Inbound Calls in Asynchronous Mode Overview

Figure 3 illustrates a Basic Inbound Call Model, which shows the call states associated with establishing a call in asynchronous mode. All calls start from a Null state. The call establishment process for inbound calls is shown in Figure 3.

See Table  6, "Asynchronous Inbound Call State Transitions" for a summary of the call state transitions.

Figure 3. Basic Asynchronous Inbound Call State Diagram

Table 6. Asynchronous 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: GCEV_ANSWERED -> Connected state GCEV_DISCONNECTED -> Disconnected state GCEV_DROP CALL -> Idle state	gc_AnswerCall( ), gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL or GCEV_ANSWERED
Call Routing (GCST_CALLROUTING) Maskable	Previous: Offered, GetMoreInfo Next: GCEV_ANSWERED -> Connected state GCEV_ACCEPT -> Accepted state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_AnswerCall( ), gc_AcceptCall( ), gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL, GCEV_ACCEPT or GCEV_ANSWERED
Connected (GCST_CONNECTED) Not Maskable	Previous: Accept, Offered, GetMoreInfo, CallRouting, Dialing, SendMoreInfo, Proceeding, Alerting Next: GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_DropCall( )	GCEV_DISCONNECTED GCEV_DROPCALL
Detected (GCST_DETECTED) Maskable	Previous: Null Next: GCEV_OFFERED -> Offered state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL, GCEV_OFFERED,
GetMoreInfo (GCST_GETMOREINFO) Maskable	Previous: Offered Next: GCEV_ANSWERED -> Connected state GCEV_MOREINFO -> GetMoreInfo state GCEV_ACCEPT -> Accepted state GCEV_CALLPROC -> CallRouting state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_ReqMoreInfo( ), gc_CallAck( ), gc_AnswerCall( ), gc_AcceptCall( ), gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL, GCEV_ACCEPT, GCEV_ANSWERED, GCEV_MOREINFO or GCEV_CALLPROC
Null (GCST_NULL) Not Maskable	Previous: Idle Next: gc_WaitCall( ) -> Null state gc_ResetLineDev( ) -> Null state GCEV_OFFERED -> Offered state GCEV_DETECTED -> Detected state	gc_WaitCall( )	GCEV_DETECTED, GCEV_OFFERED
Offered (GCST_OFFERED) Not Maskable	Previous: Null, Detected Next: GCEV_ANSWERED -> Connected state GCEV_ACCEPT -> Accepted state GCEV_CALLPROC -> CallRouting state GCEV_MOREINFO -> GetMoreInfo state GCEV_DISCONNECTED -> Disconnected state GCEV_DROPCALL -> Idle state	gc_CallAck( ), gc_AnswerCall( ), gc_AcceptCall( ), gc_DropCall( )	GCEV_DISCONNECTED, GCEV_DROPCALL, GCEV_ACCEPT, GCEV_ANSWERED, GCEV_MOREINFO or GCEV_CALLPROC

The following sections describe the asynchronous inbound call processes.

3.4.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. GCEV_BLOCKED and GCEV_UNBLOCKED events are related to layer 1 alarms, as well as to channel states (service status in T-1 ISDN, bit states in CAS). GCEV_BLOCKED and GCEV_UNBLOCKED are used as what might be termed flow-control events within the application. 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 or thread 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 asynchronous mode, the gc_WaitCall( ) function must be called only once after the line device is opened using the gc_OpenEx( ) function. However, if the gc_ResetLineDev( ) function was issued, gc_WaitCall( ) must be reissued. In asynchronous mode, it is not necessary to issue gc_WaitCall( ) again after a call is released.

Note: After gc_WaitCall( ) is issued to wait for incoming calls on a line device, it is possible to use gc_makeCall( ) to make an outbound calls on that line device.

3.4.1.3 Call Detection

The inbound call from the network is received on the line device specified in the gc_WaitCall( ) function, but the call has not been offered to the application. The technology call control layer typically sends an acknowledgement to the remote side. In some configurations, this acknowledgement can also be sent by the application when the call is offered. At this stage, the call is being processed, which typically involves allocating resources or waiting for more information. The GCEV_DETECTED event is generated, if enabled. If the GCEV_DETECTED event is generated, a new CRN is assigned to the incoming call. This event is for informational purposes to reduce glare conditions as the application is now aware of the presence of a call on the channel.

Notes:

1. For applications that use PDK protocols, if the application enables the generation of the GCEV_DETECTED event and a call disconnects while in the Detected state, a GCEV_DISCONNECTED event is received. If the application did not enable the generation of the GCEV_DETECTED event and a call disconnects while it is in the Detected state (that is, before the call enters the Offered state), the application receives a GCEV_OFFERED event with a result value of GCRV_CALLABANDONED, then a GCEV_DISCONNECTED event.
2. When developing applications that use DM3 boards, the GCEV_DETECTED event is not supported. A GCEV_DISCONNECTED event is only received if the host application already received the GCEV_OFFERED event before the remote side disconnects.

3.4.1.4 Call Offered

When an incoming call is received in en-bloc mode, where all the information required is available, the call is offered to the application by generating an unsolicited GCEV_OFFERED event (equivalent to a "ring detected" notification). This GCEV_OFFERED event causes the call to change to the Offered state. In the Offered state, a CRN is assigned as a means of identifying the call on a specific line device. If a GCEV_DETECTED event was generated before the GCEV_OFFERED event, the same CRN is assigned as the one assigned when the GCEV_DETECTED event was generated.

If the incoming call does not have sufficient information, the call is offered to the application when all the required information is received. If the technology is configured to accept minimum information, the call is offered to the application when the specified minimum amount of information is received. In this case, the application must request additional information if required. See Section 3.4.1.8, "Overlap Receiving" for more information.

A call proceeding indication can be sent by the technology call control layer, or by the application by issuing the gc_CallAck(GCACK_SERVICE_PROC) function. Otherwise the application can accept or answer the call by issuing the gc_AcceptCall( ) or gc_AnswerCall( ) functions, respectively.

Notes:

1. For applications that use PDK protocols, if the application enables the generation of the GCEV_DETECTED event and a call disconnects while in the Detected state, a GCEV_DISCONNECTED event is received. If the application did not enable the generation of the GCEV_DETECTED event and a call disconnects while it is in the Detected state (that is, before the call enters the Offered state), the application receives a GCEV_OFFERED event with a result value of GCRV_CALLABANDONED, then a GCEV_DISCONNECTED event.
2. When developing applications that use DM3 boards, the GCEV_DETECTED event is not supported. A GCEV_DISCONNECTED event is only received if the host application already received the GCEV_OFFERED event before the remote side disconnects.

3.4.1.5 Call Routing

After the call has been offered, a call proceeding indication can be sent to the remote party to indicate that all the information has been received and the call is now proceeding. This indication can be sent by the technology call control layer or by the application by issuing the gc_CallAck(GCACK_SERVICE_PROC) function. 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.4.1.6 Call Acceptance

If the application or thread 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. A GCEV_ACCEPT event is generated when the gc_AcceptCall( ) function is successfully completed and the call changes to the Accepted state. The application can then answer the call by issuing the gc_AnswerCall( ) function.

3.4.1.7 Call Establishment

When the call is to be directly connected, such as to a voice messaging system, or if the application or thread is ready to answer the call, a gc_AnswerCall( ) function is issued to make the final connection. Upon answering the call, a GCEV_ANSWERED event is generated and the call changes to the Connected state. At this point, the call is connected to the called party and call charges begin.

3.4.1.8 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 configurations:

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 (after the generation of the unsolicited GCEV_OFFERED event), the application sends an acknowledgement for the incoming call by issuing a gc_CallAck(GCACK_SERVICE_INFO) function. 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 still required, the gc_ReqMoreInfo( ) function is issued to request more information. When the information is received, the GCEV_MOREINFO event is generated again. When all the required information is received, the application may send a call proceeding indication to the remote side by issuing the gc_CallAck( ) 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. After the call is offered to the application, the address information can be retrieved to determine if more information is required. If more information is required, a gc_CallAck(GCACK_SERVICE_INFO) function must be issued. Since an acknowledgement was already sent out, nothing 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 maximum amount of information expected 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 (after generation of the unsolicited GCEV_OFFERED event), the application may selectively retrieve call information, such as the Destination 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. Since an acknowledgement was already sent out, no acknowledgement is sent to the remote side at this time. When the additional information is received, the GCEV_MOREINFO event is generated. If more information is still required, the gc_ReqMoreInfo( ) function is issued to request more information. When the additional information is received, the GCEV_MOREINFO event is generated again. 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 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. When the information is received, the GCEV_MOREINFO event is generated again. 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.4.1.9 Call Failure

The following are various causes of call failures:

Call Rejection

From the Offered state, the application or thread may reject the call by issuing the gc_DropCall( ) function followed by a gc_ReleaseCallEx( ) function (see the Global Call API Library Reference).

Forced Release

From the Accepted state, not all protocols support a forced release of the line, that is, issuing a gc_DropCall( ) function after a gc_AcceptCall( ) function. If a forced release is not supported and is attempted, the function will fail and an error will be returned. To recover, the application should issue the gc_AnswerCall( ) function followed by gc_DropCall( ) and gc_ReleaseCallEx( ) functions. However, any time 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, that is, if a GCEV_TASKFAIL event is received by the application, 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.4.1.10 Abandoned Calls

During call establishment, the remote side may choose to hang up before call setup has been completed. The application must be capable of handling error conditions and the lack of complete information when requesting call information.

One such scenario, when using PDK protocols, is the case where the remote side chooses to disconnect a call while it is between the Detected and Offered states. The resulting behavior when the call disconnects depends on whether the application has enabled the generation of the GCEV_DETECTED event:

• If GCEV_DETECTED event generation is enabled, the application will receive a GCEV_DISCONNECTED event.
• If GCEV_DETECTED event generation is not enabled, the application will receive a GCEV_OFFERED event with a result value of GCRV_CALLABANDONED, then a GCEV_DISCONNECTED event.

Global Call uses this mechanism to can keep the application informed of the incoming, but abandoned, call.

Note: When developing applications that use DM3 boards, the GCEV_DETECTED event is not supported. If the host application has not received a GCEV_OFFERED event when the call is disconnected by the remote side, the host application will not receive any event. If the host application has already received a GCEV_OFFERED event, it receives a GCEV_DISCONNECTED event when the call is disconnected.

3.4.1.11 Inbound Call Scenarios in Asynchronous Mode

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

Figure 4 shows a basic asynchronous call scenario for an incoming call.

Figure 4. Basic Asynchronous Inbound Call Scenario

Figure 5 shows an asynchronous call scenario for an incoming call with call proceeding.

Figure 5. Incoming Call Scenario with Call Proceeding

Figure 6 shows an asynchronous call scenario for an incoming call with call acknowledgement and call proceeding controlled by the application.

Figure 6. Call Acknowledgement and Call Proceeding Done at the Application Layer

Figure 7 shows an asynchronous call scenario for an incoming call with call proceeding controlled by the application with the minimum information configuration.

Figure 7. Call Proceeding Done by the Application Layer with Minimum Information Configured

Figure 8 shows an asynchronous call scenario for an incoming call with call acknowledgement and call proceeding controlled by the call control layer.

Figure 8. Call Acknowledgement and Call Proceeding Done at Technology Call Control Layer

Figure 9 shows an asynchronous call scenario for an incoming call with call acknowledgement controlled by the call control layer and call proceeding controlled by the application.

Figure 9. Call Acknowledgement Done by the Technology Call Control Layer and Call Proceeding Done by the Application

Click here to contact Telecom Support Resources