> 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 [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
