PREV TOC HOME INDEX NEXT


5.2. Handling of Glare Conditions

A glare condition occurs when an outgoing call has been initiated (gc_MakeCall( ) succeeded) and an incoming call is detected. Global Call SS7 and the SS7 stack almost completely hide this condition from the application that will see its outbound call fail and will then be notified of the inbound call.

However, in order to avoid adding delay to the handling of the inbound call, the SS7 call control library does not wait for the failed outbound call to be released before it notifies the application of the inbound call. This means that, in case of glare, the following type of scenario can be seen:

Application

Libgcs7

gc_MakeCall(crn1)
-->  
  
  
GCEV_DISCONNECTED(crn1) 
<-- 
gc_DropCall(crn1)
--> 
  
  
GCEV_OFFERED(crn2)
<-- 
gc_AcceptCall(crn2)
--> 
  
  
GCEV_DROPCALL(crn1)
<-- 
gc_ReleaseCallEx(crn1)
--> 
  

This shows that an application running on bidirectional circuits should be ready to handle two CRNs on a single line device. However, the application can be purely "reactive" with respect to the failed call (crn1) and just respond to events using their associated CRN: simply perform a gc_ReleaseCallEx( ) upon reception of any GCEV_DROPCALL, whether the CRN is the "active" one or not. Using this procedure, the application only needs to store one CRN per line device.

Another case of glare condition is at disconnection. If the application calls gc_DropCall( ) while a GCEV_DISCONNECTED has already been put in the SRL event queue, the application will receive it after it does gc_DropCall( ) when it is waiting for GCEV_DROPCALL. This late GCEV_DISCONNECTED event must be ignored by the application. The call control library will send the GCEV_DROPCALL as usual when the call is dropped. Other glare conditions at disconnection are all hidden from the application.


PREV TOC HOME INDEX NEXT

Click here to contact Telecom Support Resources

Copyright 2003, Intel Corporation
All rights reserved
This page generated January, 2003