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.](./ccsnin.gif)
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:
- A: The network signals the presence of an incoming
call. The exact method depends on the signaling protocol in use.
- 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.
- B: The signaling process reports the incoming call
by sending the SL_CALL_SETUP_IND primitive to Blueworx Voice Response.
- The channel process retrieves the call information, and starts the application
state table, based on called or calling number.
- Once the application’s state table is prepared to answer the call,
it issues the AnswerCall state table action.
- The channel process sends an SL_CALL_ANSWER_REQ primitive
to the signaling process.
- 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.
- 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.
- 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.
- Z: The signaling process sends the SL_CALL_ANSWER_CNF primitive to Blueworx Voice Response.
- The channel process has been waiting for a reply to its request.
- The channel process maps the ReplyCode to result, which is returned
to the state table.
- The AnswerCall action completes, and the state table continues
with the next action.