Silence detection (common channel signaling)

Description of flows

The flows shown in Figure 1 are as follows:

1. The application's state table issues one of the record actions, for example, RecordVoiceMessage or RecordUserGreeting. These actions record voice data from the line into Blueworx Voice Response objects.
2. During the recording a period of silence occurs which exceeds the Maximum Silence Duration system parameter. This is interpreted as the caller hanging up. The Maximum Silence Duration system parameter is described in the Blueworx Voice Response for AIX: Application Development using State Tables information.
3. The extended period of silence is detected by the signaling daemon, which is a component of Blueworx Voice Response.
4. 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.
5. The signaling process is waiting for primitives from the signaling interface using the sl_receive_request() subroutine. The sl_receive_request() completes, and the signaling process receives the SL_CALL_ABORT_REQ primitive.
6. The signaling process clears the call to the network. The signaling process should clear the call as quickly as possible.
7. 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.
8. 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 will log an error to the Blueworx Voice Response system monitor.
9. The application's Record... action terminates with the Caller Hung Up result.