Intel 05-2409-003 Manual Do Utilizador

46

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. 

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. 

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