I am not sure I understand the point you are making. Are you saying that the decision as to whether something is a newmodification, or part of an old modification, should be determined basedon the content of the SDP exchanged? That would be complex to specifyand detect. I don't want to respond further until I understand if that is what youhave in mind. If it is, can you explain exactly the criteria you woulduse to determine this? Thanks, Paul gao.yang2@xxxxxxxxxx wrote:> > If the UPDATE is a new modification, as its UPDATE/200OK pair > exchanged, the modification has commited. The Re-INVITE triggering the > old modification> has no effecting on the new modification, no matter the failure or > success of Re-INVITE(and the sequence of failure response and UPDATE).> > If the UPDATE is part of the old modification, then it should be > discard with the old modification for the failure or success of > Re-INVITE, no matter> the sequence of failure response and UPDATE.> > > > > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*> > 2009-01-14 22:13> > > 收件人> gao.yang2@xxxxxxxxxx> 抄送> Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>, sipping LIST > <sipping@xxxxxxxx>, sipping-bounces@xxxxxxxx> 主题> Re: 答复: Re: Draft: Essential correction for re-INVITE > rollback in RFC3261> > > > > > > > > A race condition occurs in some cases if the sender of a reINVITE> subsequently sends an UPDATE before receiving the final response for the> reINVITE. If a failure response to the reinvite is sent at roughly the> same time, the UPDATE may be received either *before* or *after* the> failure response is sent.> > So if we are trying to roll back any changes occurring within the> reINVITE, we then have to decide if this UPDATE is associated with the> reINVITE or not. To the UAC it certainly is. But to the UAS, it is if> received before the sending the failure response, but not if received> after sending that response. So the UAC will always roll it back, and> the UAS will *sometimes* roll it back, and sometimes not. This of course> will lead to trouble.> > Thanks,> Paul> > gao.yang2@xxxxxxxxxx wrote:> >> > Adding more expatiation on it:> >> > If latter Offer/Answer(such as in UPDATE/200OK) having nothing to do> > with the original modification triggering by Re-INVITE, it is just a new> > modification> > as the original one. Its commit/rollbak having nothing to do with> > Re-INVITE(and its failure).> >> > But if latter Offer/Answer(such as in UPDATE/200OK) having association> > with the original modification triggering by Re-INVITE, it should be> > explained with> > nest transaction semantics. *I just explained it using nest transaction> > concept, without introducing any new definition.*> >> > I find that current well known extension usage of Offer/Answer such as> > precondition(and others) just keeping to the explanation using nest> > transaction concept. *The nest transaction concept is the nature> > property of such extension usage of Offer/Answer*, not my invention.> > Such as suspending of session establishment/modification.> >> > How extension usage of Offer/Answer *define the association of latter> > Offer/Answer and the original modification is the responsibility of the> > extension usage itself*. And it *should be open for extension usage of> > Offer/Answer in the future*.> > I just point out this, I mean all of this is just clarify, no definition.> >> >> >> > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*> >> > 2009-01-13 22:21> >> > > > 收件人> > Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>> > 抄送> > gao.yang2@xxxxxxxxxx, sipping-bounces@xxxxxxxx, > sipping LIST> > <sipping@xxxxxxxx>> > 主题> > Re: [Sipping] 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.> >> > 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.> >> > Thanks,> > Paul> >> > Christer Holmberg wrote:> > > > > > > > >> > >> Why we do not choose automatic fallback by two peer(UAC and UAS) to> > rollback to the state before Re-INVITE , while it has no ambiguous state> > of session.> > >> (please refer to "draft-gaoyang-sipping-session-state-criterion-00")> > >> > > We were actually planning to choose full rollback (to the state> > before the re-INVITE), but then someone raised a race condition problem.> > I don't remember the name of the thread discussing that, though.> > >> > > > > >> While automatic fallback has no fault, so I think it is no a better> > solution to use "manual fallback".> > >> > > See the thread about the race condition.> > >> > >> > >> 1、"manual fallback" has race condition too, while the two peer> > issue its own Re-INVITE/UPDATE. And I think "manual fallback" is much > more> > >> like a refresh process. It may be a optional process, but it can not> > be the theoretical explanation.> > >> > > The protocol can deal with the case when two peers send > re-INVITE/UPDATE.> > >> > > The race condition (ok, maybe the wording is bad) was related to the> > fact that the UAS does not know whether an offer is sent before or after> > the UAC received the re-INVITE error response.> > >> > >> > >> 2、I am glad to get your comments on> > "draft-gaoyang-sipping-session-state-criterion-00", which has the> > attitude that> > >> there has no ambiguous state of session for unsuccessful Re-INVITE.> > >> > > >> "draft-gaoyang-sipping-session-state-criterion-00" has no new> > definition or violation of current RFC, it is just clarification for> > >> debate on the topic of "Commit/Rollback of Offer/Answer on> > Unsuccessful re-INVITE". > > >> > > Please try to look for the problem I mentioned above, and see whether> > you think it can be solved.> > >> > >> > > Regards,> > >> > > Christer> > >> > >> > > > > > > > > > > > > > > > > > > > > > > > "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>> > >> > > 2009-01-13 15:33> > >> > > > > > 收件人> > > <gao.yang2@xxxxxxxxxx>> > > 抄送> > > "sipping LIST" <sipping@xxxxxxxx>,> > <sipping-bounces@xxxxxxxx>> > > 主题> > > RE: RE: [Sipping] Draft: Essential> > correction for re-INVITE rollback in RFC3261> > >> > > > > >> > >> > >> > >> > > > > > Hi,> > > > > > I agree that pre-conditions may be performed before> > the user is prompted, which may then cause the re-INVITE to fail. That> > was also previously discussed on the list.> > > > > > Now, if resources have been reserved, and the> > re-INVITE fails, there is nothing which prevents entities to release> > those resources.> > > > > > Also, if additional m- lines have been added, you> > will need to send a new re-INVITE/UPDATE to remove it. That's what we> > call a "manual fallback".> > > > > > Also, if you look at the old thread, there was a> > discussion about a possible race condition which could occur if you do a> > full fallback.> > > > > > Regards,> > > > > > Christer> > > > > > > > > > > > > > > > > > ________________________________> > >> > > From: gao.yang2@xxxxxxxxxx> > [mailto:gao.yang2@xxxxxxxxxx]> > > Sent: 13. tammikuuta 2009 2:43> > > To: Christer Holmberg> > > Cc: sipping LIST; sipping-bounces@xxxxxxxx> > > Subject: 答复: RE: [Sipping] Draft: Essential> > correction for re-INVITE rollback in RFC3261> > > > > > > > > > > "draft-gaoyang-sipping-session-state-criterion-00.txt", clarify that> > there is no> > > ambiguous state of session modification using> > current RFC definition.> > > Just using current RFC definition， and without> > violation or new definition.> > > > > > My points of view:> > > > > > 1、It should make the user have the capability to> > accept or refuse session modification> > > (see "Intuitionistic(user point of view) requirement> > for rejecting session modification").> > > > > > In my points of view, IMS(3GPP) as the multimedia> > platform, it should be enriched with> > > this intuitionistic(user point of view) requirement.> > > > > > Considering precondition, it is always exchange> > offer/answer(and modified the session parameters)> > > before prompting the end user.> > > > > > 2、offer/answer is atomic, but it can be part of a> > nested transaction. Such as modification with precondition> > > may have more than one offer/answer pair. So the> > modification is atomic, and the offer/answer is its part.> > > > > > If the precondition is not just about resource> > reservation(for example, two precondition, one about> > > resource reservation, another about other> > application aspect).> > > So when meeting precondition about resource> > reservation, the session parameters have been modified(sucessfully).> > > But if the precondition about other application> > aspect is not meeted, this modification should be discard.> > > > > > So, how the application level will using the> > offer/answer as part of a nested transaction, is just beyond the> > offer/answer definition.> > > And we should open the gate for the application> > level extention.> > > > > > > > > > > > > > > > > > "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>> > >> > > 2009-01-12 18:08> > >> > > > > > > > > 收件人> > > <gao.yang2@xxxxxxxxxx>> > > 抄送> > > "sipping LIST" <sipping@xxxxxxxx>,> > <sipping-bounces@xxxxxxxx>> > > 主题> > > RE: [Sipping] Draft: Essential> > correction for re-INVITE rollback in RFC3261> > >> > >> > > > > >> > >> > > > > > > > > > > > > > > Hi,> > > > > > > > > >1.> > > >In "draft-ietf-sipping-sip-offeranswer-08.txt ",> > there is a use case:> > > >The case of> > > >adding a new media (like adding video to audio only> > session) which> > > >requires permission from the peer through some user> > interaction is> > > >one example.> > > >From the user's viewpoint, he(or she) just reject> > the modification of session, so> > > >the offer/answer should be rollback.> > > >So, "any session> > > >parameters that have been sucessfully changed> > during the duration of> > > >the re-INVITE transaction MUST remain unchanged" is> > not reasonable for all> > > >application use case.> > > > > > > > > We have agreed that we cannot define different rules> > for different use-cases. We need to have a generic rule, and> > implementors shall then use that.> > > > > > There was a long discussion on which solution to go> > for, and the text now reflects the agreed solution (which we also> > informed 3GPP about).> > > > > > Regards,> > > > > > Christer> > > > > > > > > > > > > > > 2.> > > There are nested transactions concept> > in application level above of offer/answer> > > which use a offer/answer pair as a> > sub-transaction. So, commit/rollback is not just> > > offer/answer issue, it is a> > application issue(such as precondition may have more than> > > one offer/answer pairs).And> > application level usage of offer/answer should be open for> > > the future extension.> > > > > > 3.> > > I just submitted a draft talking> > about session state 2009-01-08:> > > > > > > > https://datatracker.ietf.org/idst/status.cgi?submission_id=11690> > > > > > the document URL:> > > > > > > > > http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-00.txt > > >> > > > > > (the URL> > > "http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-01.txt"; > > >> > > is not available, but the 00.txt is> > the current one)> > > > > > > > > > > > > > > > > > "Christer Holmberg"> > <christer.holmberg@xxxxxxxxxxxx>> > > 发件人: sipping-bounces@xxxxxxxx> > > > > > 2009-01-09 17:32> > > > > > > > > 收件人> > > "sipping LIST"> > <sipping@xxxxxxxx>> > > 抄送> > > > > > 主题> > > [Sipping] Draft:> > Essential correction for re-INVITE rollback in RFC3261> > > > > > > > > > > > > > > > > > > > > > > > Hi,> > > > > > I've put together the first version> > of the draft related to the re-INVITE follback fix, based on the agreed> > solution.> > > > > > I had some problems with the IETF> > submission tool, but the draft can be found at:> > > > > > > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt > > > > <http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt> > > > > > > > > > Regards,> > > > > > Christer> > _______________________________________________> > > 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.> > > > > > > > > > > > > --------------------------------------------------------> > > 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/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
