5.2 Fatal Error Recovery

A fatal error can be defined as any error that will cause a channel to hang. There are several types of fatal errors:

• Fatal errors where a recovery attempt is possible via sending the protocol a protocol reset command.
• Fatal errors where no recovery attempt is possible except by closing the channel and re-opening it.
• Fatal errors where no recovery attempt is possible; the application must be shut down and restarted. An example of this is an internal error in a call control library. Normally, this should not occur.

The following fatal error recovery scenario is only possible when using PDKRT protocols.

When a fatal error where an internal recovery attempt is possible is caught, the application is notified by the GCEV_FATALERROR event, with a result value of GCRV_RESETABLE_FATALERROR, that a recovery from a fatal error is in progress. The application then assumes a gc_ResetLineDev( ) has been done and waits for the gc_ResetLineDev( ) completion event (GCEV_RESETLINEDEV). The application does not need to drop any active calls; dropping of calls occurs automatically.

When a fatal error where an internal recovery attempt is not possible, but an error that is non-fatal is caught, the application is notified by the GCEV_FATALERROR event, with a result value of GCRV_RECOVERABLE_FATALERROR, indicating that the application needs to issue a gc_Close( ) followed by a gc_OpenEx( ).

When a fatal, non-recoverable error is caught, the application is notified by the GCEV_FATALERROR event with a result value of GCRV_NONRECOVERABLE_FATALERROR. The application must then shut down. The firmware should then be reloaded, and the application restarted.

If the application makes any requests while the recovery process is in progress, the request will fail. In asynchronous mode, the application is notified by a GCEV_TASKFAIL event with a reason of GCRV_FATALERROR_OCCURRED. In synchronous mode, the application receives a -1 indicating that an error has occurred. The error value for the failure is EGC_FATALERROR_OCCURRED. Similarly, if any requests are in the queue, a check is performed to see if fatal error recovery is in progress. If it is in progress, then the request will fail with a reason of GCRV_FATALERROR_OCCURRED.

The following errors are not handled automatically:

• errors during open
• errors during close
• errors during start
• errors during stop
• lack of dynamic memory
• recursive errors (errors that occurred while recovering)

For a listing of the error codes and result values used in fatal error recovery, see the Global Call API Library Reference.

Click here to contact Telecom Support Resources