1.14. Handling Glare Conditions

Two common glare conditions and the recommended methods for handling them are described below:

• Receiving a GCEV_TASKFAIL event when using gc_MakeCall( ) or gc_SndMoreInfo( ):
  • When using Springware boards, while making an outbound call, if the application receives a GCEV_TASKFAIL event (related to some failure) before it receives a response to the SETUP message, the gc_MakeCall( ) should be considered as having failed. In the case of overlapped sending, the first response is a GCEV_REQMOREINFO event; any GCEV_TASKFAIL event received subsequently should not be considered a gc_MakeCall( ) failure.
  • When using DM3 boards, this does not apply since a GCEV_TASKFAIL event is not received when using gc_MakeCall( ) or gc_SndMoreInfo( ). Typically, a GCEV_DISCONNECTED event is received instead.

  
  Note: For both Springware and DM3 boards, while sending the overlapped digits using gc_SndMoreInfo( ), if the answering side accepts or answers the call, depending on the glare, the GCEV_SNDMOREINFO event may not be generated. The application should not wait for this event after getting GCEV_ALERTING, GCEV_PROCEEDING or GCEV_CONNECTED.
  

• Receiving a GCEV_DISCONNECTED event when using gc_AccetpCall( ) or gc_AnswerCall( ):

  While accepting or answering an incoming call, if the DISCONNECTED message arrives before the gc_AcceptCall( ) or gc_AnswerCall( ) completes, the application does not receive a GCEV_ALERTING or GCEV_ANSWERED event. Instead:

  • When using Springware boards, the application receives a GCEV_TASKFAIL event with a reason of 0x10F that is, "Cannot accept event in current state". This is not a serious failure and the application can continue to drop and release the disconnected call and reuse the channel without having to restart it.
  • When using DM3 boards, the application receives a GCEV_DISCONNECTED event.

Click here to contact Telecom Support Resources