Aborting a request

At any time after a primitive is received, even after a confirm has been sent, the SL_ABORT_REQ primitive may be received. This asks the signaling process to abort processing of a specified primitive. The SL_ABORT_REQ primitive should not be replied to itself, it indicates that a reply is required for the primitive in progress. If there is a primitive outstanding that matches the SL_ABORT_REQ primitive, abort the primitive and reply with SL_REPLY_ABORT. If the outstanding primitive cannot be aborted, reply as usual when the processing completes. If there is no primitive outstanding that matches the SL_ABORT_REQ primitive, ignore the request and log an error.

The primitives involved when a call setup is successfully aborted are shown in Figure 1.

Figure 1. Primitives involved when a request is aborted successfully

The sequence shown in this graphic begins with the state table issuing MakeCall and the Channel process sending the SL_CALL_SETUP_REQ primitive (with the appropriate iseqno) across the signaling interface to the signaling process. The signaling process establishes a call on the line but there is no reply within an acceptable time. The Channel process therefore sends the SL_ABORT_REQ primitive, quoting the appropriate iseqno, and the signaling process clears the call to the network before returning the SL_CALL_SETUP_CNF primitive to the Channel process with the Reply code SL_REPLY_ABORTED. The Channel process returns the No Answer result to the state table.