Channel process failure (common channel signaling)

This section describes the sequence of events following a channel process failure.

Figure 1. Common channel signaling process: channel process failure
The graphic is a very simplified representation of the process described in detail in the next section.

Description of flows

The flows shown in Figure 1 are as follows:

  1. A failure occurs in the channel process interpreting the application’s state table.
  2. The failure of the channel process is detected by the signaling daemon, which is a component of Blueworx Voice Response.
  3. The signaling daemon creates an SL_CALL_ABORT_REQ primitive, and sends it to the signaling process responsible for the call. The SL_CALL_ABORT_REQ primitive is an instruction to the signaling process to clear the call to the network.
  4. The signaling process is waiting for primitives from the signaling interface using the sl_receive_request() subroutine. The call to sl_receive_request() completes, and the signaling process receives the SL_CALL_ABORT_REQ primitive.
  5. The signaling process clears the call to the network. The signaling process should clear the call as quickly as possible.
  6. After the call is cleared, the signaling process creates an SL_CALL_ABORT_CNF primitive, and sends it to the signaling daemon using the sl_send_confirm() subroutine call.
  7. The signaling daemon is waiting for the reply from the signaling process, by using the sl_receive_confirm() subroutine. If the signaling process does not send back the SL_CALL_ABORT_CNF primitive, or if the ReplyCode in the primitive is not SL_REPLY_SUCCESS, the signaling daemon logs an error to the Blueworx Voice Response system monitor.