Hi, If we want to go for a solution where the precondition state matters, there is one issue: Assume that one side has indicated that his preconditions are met, but the other side has still not indicated it. What happens now if the re-INVITE fails? I ASSUME we would have to say that if all preconditons - on both sides - are met, the change is comitted and there is no fallback. If the preconditions are met only on one side, and the re-INVITE fails, there is a fallback. Or? In addition, there is also the "late commitment" concept by Gao. I am afraid that we make all this too complicated for its own good. The easiest solution is to say that all changes are commited (or current agreement), OR that there is always a full rollback if the re-INVITE fails. The second alternative was favored e.g. by Paul, but the problem was the UPDATE race condition. But, that could be solved by the BCP proposal by Gao: use UPDATEs only "inside" a re-INVITE transaction. It is also quite difficult to discuss this per e-mail: a face-to-face meeting, with a big whiteboard, would be much better. But, AFAIK many of the key persons in this issue are not coming to SFO, so I don't know when such meeting could take place... Regards, Christer -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Gonzalo Camarillo Sent: Thursday, February 26, 2009 1:43 PM To: sipping Subject: Closing the offer/answer rollback issue Folks, it is time to close the offer/answer rollback issue. We need to make a decision and move forward. We face this issue when one or more offer/answer exchanges are successfully completed within a re-INVITE that ends up failing. The question is, what should the session state be after the re-INVITE fails. For more details on this issue, see: http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-10#section -6.2 A more-or-less straight forward solution would be to specify that the session state should be that of the last offer/answer exchange that was completed successfully. We lose the atomicity of the re-INVITE, but it is a price most people seem willing to pay according to our discussions. Now, there is an additional issue with this solution. What happens if the last successfully completed offer/answer exchange contained preconditions that were never met? In that case, media changes in that offer/answer exchange that were affected by the preconditions had not been executed. Per RFC3312: http://tools.ietf.org/html/rfc3312#section-6 "However, offers containing preconditions sent in the middle of an ongoing session need further explanation. Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. " A solution to this issue could be to specify that, when the re-INVITE fails, the session state should be that which is *in use* at that point. Of course, we need to clarify what "in use" exactly means. The idea would be the following: An INVITE request establishes a session: INVITE ------------------> 200 <------------------ After this first offer/answer exchange, we have an audio stream and a video stream using the following codecs: audio stream: audio codec 1 video stream: video codec 1 Now we have a re-INVITE with an offer that changes the codec for the audio stream to audio codec 2 and the video codec to video codec 2. The change in the video codec is subject to preconditions. The answer arrives in a reliable 1xx response: audio stream: audio codec 2 video stream: video codec 2 (subject to preconditions) re-INVITE ------------------> 1xx <------------------ Now, the session state in use is the following: audio stream: audio codec 2 video stream: video codec 1 The video codec has not been changed (yet) because the preconditions for the video stream has not been met yet. Now, the re-INVITE fails with a 4xx response. The session state *in use* would be the one above, which is a mixture between the first the second offer/answer exchanges. The state of the audio stream comes from the second exchange while the state of the video stream comes from the first exchange (because the preconditions in the second exchange for that media stream were never met). At this point, the endpoints could perform a new offer/answer exchange just to make sure they both are on the same page. Do people think it would be worthwhile specifying/clarifying this *in use* concept? We would appreciate comments on this because, as stated above, we would like to close this in a relatively short time. Thanks, Gonzalo _______________________________________________ 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 _______________________________________________ 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
