> Yes. But I did not mean automatically. > > The process of termination of session should obey RFC3261. > > IMO, BYE is *recommended*. Cancel would terminate other forking branch. > > How to do it is just complementarity of RFC3262, not overthrow of it. I was attempting to emphasis how PRACK 481 should be interpreted instead of how the UAC should release things. My apologies if "not automatically" added to the confusion; the use of "not automatically" was to indicate that UAC may still initiate termination when UAS is not indicating that it should. The PRACK 481 has the same meaning as CANCEL 481. Thus the PRACK 481 should not automatically cause the UAC to initiate termination of the dialog usage (by sending BYE, sending CANCEL, exploding, or other means). RFC 3262 section 3: "If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response." RFC 3261 section 9.2: "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)." RFC 5057 section 5.1 note 8: "The 481 response to a CANCEL request has to be treated differently. For CANCEL, a 481 means the UAS can't find a matching transaction. A 481 response to a CANCEL affects only the CANCEL transaction. The usage associated with the INVITE is not affected." > And I am not sure that really we need to give out a detail process > for behaviour of violation of *MUST NOT*. What "MUST NOT"? The following two quotes clearly indicate PRACK 481 and other PRACK failure responses can be sent. RFC 3262 section 3: "PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261." RFC 3262 section 3: "If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response." _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
