So what I understand is if there is a use-case where CANCEL can be sent for other than non-INVITE method, that case should be clearly outlined... may be a sip extension rfc which specifically standardizes such scenario. Otherwise if not explicitely mentioned CANCEL should be ignored in case of non-INVITE requests. If my understanding is correct then it raises a question that what a UAS should send in response of CANCEL for a non-INVITE request even if UAS decides to ignore it?
Thanks, Arun On Sep 17, 2013 4:51 PM, "Brett Tate" <br...@broadsoft.com> wrote: > > Is it possible to send a CANCEL request for non-INVITE > > requests as well? In section 9 its written CANCEL is > > best suited for INVITE. However the standard does not > > restrict CANCEL only for INVITE. Moreover, In 9.1 its > > written cancel SHOULD NOT be sent for requests other > > than INVITE. But to mandate a MUST NOT should be written. > > Any thoughts on this. > > You are interpreting RFC 3261 correctly. I doubt anyone will find an > acceptable reason to violate the SHOULD NOT. RFC 2543 was more lenient > concerning sending CANCEL; however RFC 3261 requires the 1xx and indicates > useless except for INVITE. > > RFC 3261 section 9.1: > > A CANCEL request SHOULD NOT be sent to cancel a request other than > INVITE. > > Since requests other than INVITE are responded to immediately, > sending a CANCEL for a non-INVITE request would always create a > race condition. > > RFC 3261 section 9.1: > > 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. > > RFC 2119: > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
