Hi, >If it is a new modification, it should be commited. > >The failure of Re-INVITE just show the ending of the old modification. > >Modification is exclusive, so when the new one is in process, the old one has discarded. Isn't this exactly what we are trying to say? When the re-INVITE fails, any old UPDATE/PRACK modification remains unchanged. But, it seems like you want some types of modifications to remain unchanged, and others to be rolled back to the state BEFORE the re-INVITE, beased on the "association" with the re-INVITE. You need to give a generic definition for that association. We can not list detailed use-case, and say which is associated and not, because then we need to figure out every possible use-case and say whether they are associated or not. Regards, Christer "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx> 2009-01-14 14:46 收件人 <gao.yang2@xxxxxxxxxx>, "Brett Tate" <brett@xxxxxxxxxxxxx> 抄送 "Paul Kyzivat" <pkyzivat@xxxxxxxxx>, "sipping LIST" <sipping@xxxxxxxx>, <sipping-bounces@xxxxxxxx> 主题 RE: Re: Draft: Essential correction for re-INVITE rollback in RFC3261 Hi, >If Re-INVITE issues session modification of adding new media component(such as vedio), and the modification is rejected by the peer. > >The media parameters may changed successfully before rejection(such as precondition), the media parameters should rollback. > > > > My main attitude is that: > > 1、Offer/Answer after the Re-INVITE may be part of the modification issued by Re-INVITE. Such as UPDATE(with precondition notification) and PRACK(refine codecs in 3GPP usage). Correct. But, the UPDATE may also be used for something ELSE than precondition notification. > 2、If Offer/Answer after the Re-INVITE is a new modification, it has nothing to do with Re-INVITE and its failure. (we have no reason to say that > the the new successful modification should be commited by the signal(2XX of Re-INVITE) associate to the original > modification request.) Isn't that what we are saying? If I send UPDATE after re-INVITE, and receive 2xx for UPDATE, whatever was changed in the UPDATE transaction stays changed. It doesn't matter if I then receive non-2xx for the re-INVITE. It would be much easier if we had a dedicated SIP request for precondition notifications (we used to have COMET, didn't we? :). We could then say that it is fully rolled back if the re-INVITE fails. The problem now is that UPDATE can be used for precondition notficiations AND actual parameter changes. Regards, Christer draft: URL: http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-00.txt Brett Tate <brett@xxxxxxxxxxxxx> 发件人: sipping-bounces@xxxxxxxx 2009-01-14 03:47 收件人 Paul Kyzivat <pkyzivat@xxxxxxxxx>, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>, sipping LIST <sipping@xxxxxxxx> 抄送 主题 Re: Draft: Essential correction for re-INVITE rollback in RFC3261 > Just to support Christer: I was initially in favor of the > full rollback approach. But the discussion showed that it > had the race condition that Christer mentions. We > considered introducing additional machinery to resolve > that race, but that just complicated things further, > especially backward compatibility, for an obscure case. > > So, I have come to understand that there is no ideal > answer, and so am satisfied with the one that was chosen. As mentioned within an August thread, I'm not necessarily opposed to the adjustment. http://www.ietf.org/mail-archive/web/sipping/current/msg16073.html However as mentioned within an email I sent Friday, I'm currently still unsure of the specifics of the chosen approach. What is the meaning of "successfully" updated/changed as criteria to not rollback session parameters? What are the rules concerning non session parameters (such as Contact)? http://www.ietf.org/mail-archive/web/sipping/current/msg16567.html > I realize that not everybody knows all the history of > this, so we explain it again, but we can't re-open the > decision at this point. Since the decision has been made, hopefully somebody knows the answers to the above questions. Thanks, Brett _______________________________________________ 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 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
