4.3 Blocked and Unblocked Event Handling

Global Call uses the concept of blocked and unblocked conditions for line devices. By default, when the gc_OpenEx( ) function is used to open a line device, the line device is in a blocked condition meaning that the application can not perform call related functions on the line device, such as waiting for a call or making a call. The application must wait for the GCEV_UNBLOCKED event before waiting for a call or making a call.

Note: Since, by default, the line device is initially in the blocked condition, the application does not receive an initial GCEV_BLOCKED event.

Circumstances can occur, such as a blocking layer 1 (physical) alarm or the remote side going out of service, that cause a line device to move to a blocked condition. When this happens, the application receives a GCEV_BLOCKED event. When the line device is in the blocked condition, the application can only perform a small subset of the valid functions for line devices. The functions common to all interface technologies and that can be used while a line device is in the blocked condition are:

• gc_DropCall( )
• gc_ReleaseCall( )
• gc_ReleaseCallEx( )
• gc_Close( )
• Functions related to alarm processing and retrieving alarm information, for example, gc_AlarmName( ).
• Functions related to error processing, for example, gc_ErrorInfo( ).
• Functions related to event processing, for example, gc_ResultInfo( ), gc_GetMetaevent( ) and gc_GetMetaeventEx( ).
• Functions related to retrieving information about the call control libraries, for example, gc_CCLibIDToName( ).
• gc_AttachResource( ) and gc_Detach( )

As indicated in the list above, the application may drop and release calls while a line device is in the blocked condition, but it should not do so in response to the GCEV_BLOCKED event. If a call is active, typically a GCEV_DISCONNECTED event arrives either just before or just after the GCEV_BLOCKED event, at which point the application should drop and release the call indicated by the GCEV_DISCONNECTED event.

Note: The Global Call term blocked does not refer to the signaling bits indicating a blocked condition as defined in some network interface technologies, although the line device may move to a blocked condition as a consequence of the signaling bits indicating a blocked condition.

At some point, the application may receives a GCEV_UNBLOCKED event, indicating that the conditions blocking a line device have been removed and the line device has now returned to the unblocked condition. The application can once again use the any valid function on the line device.

The reception of the GCEV_BLOCKED and GCEV_UNBLOCKED events may be disabled using the gc_SetConfigData( ) function. The default is that these events are enabled. However, disabling the reception of these events is not recommended since the application will not be notified of these critical events. In addition, if the GCEV_BLOCKED event is disabled, some functions will fail with a reason of EGC_INVALIDSTATE, which may cause confusion. For more information on blocking alarms and the GCEV_BLOCKED and GCEV_UNBLOCKED events, see Section 8.2.1, "Generation of Events for Blocking Alarms".

Note: A GCEV_UNBLOCKED event will be generated when opening a board device. A GCEV_BLOCKED event will also be generated if there are blocking alarms on the board and the corresponding GCEV_UNBLOCKED event will be generated when the blocking alarms clear. The application must be prepared to handle these events.

Click here to contact Telecom Support Resources