>>> Regarding your second bullet, I don't even think that one >>> should send "nested" UPDATEs, if they don't have anything >>> to do with the re-INVITE. I think that is bad application >>> design. Non-related changes should be done outside the >>> re-INVITE transaction. >> >> Sending UPDATE per RFC 4028 to refresh or audit the dialog >> is one of the times UPDATE may be tried while a re-INVITE is >> occurring. > > True, but normally those UPDATEs are not going to modify session > parameters. > > So, yes, it may happen, but I think we should recommend > against doing so. There are two key phrases within rfc3261 which might be adding to the confusion: "session parameters" and "state changes". RFC 3261 section 12.2.2 and 14.1 basically indicate to rollback as though the re-INVITE was not sent. There have been numerous proposal concerning what should and shouldn't rollback; it is occasional hard to distinguish if people mean 1) SDP 2) non SDP state data (like Contact, Session-Expires, ...), or 3) both. I agree that UPDATE likely wouldn't include SDP when only attempting to refresh or audit the session; however it can. I think 12.2.2 is sufficiently clear concerning what should occur upon re-INVITE failure; however I think it was unfortunate that section 14.1 indicated "session parameters" instead of "state changes". RFC 3261 section 12.2.2: "Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed." Concerning UPDATE in relation to section 12.2.2, I consider it an atomic transaction. And for it is worth, I consider PRACK to not be an atomic transaction. _______________________________________________ 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
