Unsuccessful incoming call (common channel signaling)

This section describes the sequence of events when Blueworx Voice Response receives an incoming call destined for an application.

Figure 1. Common channel signaling process: unsuccessful incoming call
The graphic is a very simplified representation of the process described in detail in the next section. The graphic shows the phases that are explained there.

Error processing

Blueworx Voice Response provides error processing to ensure that a call is never left connected in the event of failure. This table shows what Blueworx Voice Response does when a channel process failure occurs at different stages during an incoming call:

Phase

Error Processing

A, B

None.

C

Send the SL_CALL_ABORT_REQ primitive to the signaling process.

Z

None.

Description of flows

The flows shown in Figure 1 are as follows:

  1. A: The network signals the presence of an incoming call. The exact method depends on the signaling protocol in use.
  2. The signaling process receives this notification. The signaling process then creates an SL_CALL_SETUP_IND primitive, and fills in the call information fields based on the messages received from the network.
  3. B: The signaling process reports the incoming call by sending the SL_CALL_SETUP_IND primitive to Blueworx Voice Response.
  4. The channel process retrieves the call information, and starts the application state table, based on called or calling number.
  5. Once the application’s state table is prepared to answer the call, it issues the AnswerCall state table action.
  6. The channel process sends an SL_CALL_ANSWER_REQ primitive to the signaling process.
  7. C: The signaling process receives the SL_CALL_ANSWER_REQ primitive. This is its cue to inform the network that Blueworx Voice Response wants to accept the call.
  8. If, in the meantime, the network has already cleared the offered call, perhaps because the caller has put the phone down, the call cannot be connected. Or, if the signaling process signals to the network to accept the call, but is unsuccessful, the call cannot be connected. In both cases the channel process must be informed of the failure.
  9. The signaling process creates an SL_CALL_ANSWER_REQ primitive. The Replycode field must be set to a value other than SL_REPLY_SUCCESS to indicate the reason that the call could not be answered. See SL_CALL_ANSWER_CNF primitive for a description of how the relevant values of the SL_REPLY_CODE enumeration are interpreted by Blueworx Voice Response. Use the ISDN-UP cause indicator parameter, if it is available, (or its equivalent for other signaling procotols) to select the most appropriate ReplyCode.
  10. Z: The signaling process sends the SL_CALL_ANSWER_CNF primitive to Blueworx Voice Response.
  11. The channel process has been waiting for a reply to its request.
  12. The channel process maps the ReplyCode to result, which is returned to the state table.
  13. The AnswerCall action completes, and the state table continues with the next action.