[SIPForum-discussion] : Invite Cancel Response sequence

[Garron, James]

RFC3261 secition 9.2 'Canceling a Request':

 

 

9.2 Server Behavior 

The CANCEL method requests that the TU at the server side cancel a
pending transaction. The TU determines the transaction to be cancelled
by taking the CANCEL request, and then assuming that the request method
is anything but CANCEL or ACK and applying the transaction matching
procedures of Section 17.2.3
<file:///C:\Misc\Protocols\SIP\RFC3261%20SIP.htm#sec-17.2.3#sec-17.2.3>
. The matching transaction is the one to be cancelled. 

The processing of a CANCEL request at a server depends on the type of
server. A stateless proxy will forward it, a stateful proxy might
respond to it and generate some CANCEL requests of its own, and a UAS
will respond to it. See Section 16.10
<file:///C:\Misc\Protocols\SIP\RFC3261%20SIP.htm#sec-16.10#sec-16.10>
for proxy treatment of CANCEL. 

A UAS first processes the CANCEL request according to the general UAS
processing described in Section 8.2
<file:///C:\Misc\Protocols\SIP\RFC3261%20SIP.htm#sec-8.2#sec-8.2> .
However, since CANCEL requests are hop-by-hop and cannot be resubmitted,
they cannot be challenged by the server in order to get proper
credentials in an Authorization header field. Note also that CANCEL
requests do not contain a Require header field. 

If the UAS did not find a matching transaction for the CANCEL according
to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call
Leg/Transaction Does Not Exist). If the transaction for the original
request still exists, the behavior of the UAS on receiving a CANCEL
request depends on whether it has already sent a final response for the
original request. If it has, the CANCEL request has no effect on the
processing of the original request, no effect on any session state, and
no effect on the responses generated for the original request. If the
UAS has not issued a final response for the original request, its
behavior depends on the method of the original request. If the original
request was an INVITE, the UAS SHOULD immediately respond to the INVITE
with a 487 (Request Terminated). A CANCEL request has no impact on the
processing of transactions with any other method defined in this
specification. 

Regardless of the method of the original request, as long as the CANCEL
matched an existing transaction, the UAS answers the CANCEL request
itself with a 200 (OK) response. This response is constructed following
the procedures described in Section 8.2.6
<file:///C:\Misc\Protocols\SIP\RFC3261%20SIP.htm#sec-8.2.6#sec-8.2.6>
noting that the To tag of the response to the CANCEL and the To tag in
the response to the original request SHOULD be the same. The response to
CANCEL is passed to the server transaction for transmission. 

 

 

________________________________

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of chethan prakash
Sent: Wednesday, October 07, 2009 6:41 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] : Invite Cancel Response sequence

 

Hello All,

 

Can you please kindly clarify if there is anything wrong the below
mentioned INVITE Cancel Response Sequence, 

 

UE 1                                    UE 2

    --------------INVITE-----------------> 

    <---------- 100 Trying---------------

    <---------- 180 Ringing-------------

    -------------CANCEL----------------> 

    <---------- 487 (INVITE)------------

    <---------- 200 OK (CANCEL)----

 

Please forward me the RFC Section where it is stated that on receiving
cancel we should respond to Cancel Request first before we send final
response to Invite Request.

 

 

Regards,

Chethan

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20091008/f3ae2512/attachment-0002.html>