46 Global Call API for HMP on Windows Programming Guide — August 2006
Call State Models
address (caller ID) by issuing the gc_GetCallInfo() function. If m ore 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 (applies to E1, T1 and ISDN technologies only)
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 F ail ure
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