gao.yang2@xxxxxxxxxx wrote:> > I do not use English as mother tongue. So I am not sure the meaning of > "reluctant". Does it means:> > 1. you do not prefer to accept it;> 2. you accept it, but without pleasure.
I prefer not to accept it. But that is my personal opinion.It is up to the group to collectively decide if such a change is to be made.
> Currently, we just need to distinguish precondition notification SDP > from others. And the classification is clear.
It may be clear in some cases, but I don't think it is necessarily clearin all cases.
For instance, suppose the SDP contains two m-lines. Preconditions arebeing negotiated for one of them, but not for the other. Possibly othersorts of changes (e.g. codec selection) are being made for the other.
I'm concerned that we will get into unending discussions of which casesare part of a single "transaction" and which are not.
I will note that I was originally in favor of the rollback, but wantedit to be unconditional on the types of changes that had been made. Theambiguity in determining if an UPDATE is without the INVITE or notcaused me to give up on that.
Thanks, Paul
Thanks, Paul
> And session state is the base of rich and complex media types in the > future.> > To be honest, when I first thought the "rollback of Re-INVITE" issue one > years ago, I find it is too hard to combine the points such as > precondition, committing by 200OK(Re-INVITE). And it puzzled for almost > one year, while I want to solve it in academic way.> When I realize I should using nested transaction concept, I find that > all the doubt disapear. And I am happy to find that I did not introduce > any new definition and these is no violation to current RFCs.> > > > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*> > 2009-01-17 00:30> > > 收件人> gao.yang2@xxxxxxxxxx> 抄送> Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>, Brett Tate > <brett@xxxxxxxxxxxxx>, sipping LIST <sipping@xxxxxxxx>, > sipping-bounces@xxxxxxxx> 主题> Re: 答复: RE: RE: Re: Draft: Essential correction for > re-INVITE rollback in RFC3261> > > > > > > > > I am very reluctant to make the decision of whether to roll back the> state dependent on the particular content of the SDP that has been> exchanged.> > Thanks,> Paul> > gao.yang2@xxxxxxxxxx wrote:> >> > Another evidence show the importance of session state:> >> > In RFC4566(5.13. Attributes ("a=")):> > Attribute interpretation *depends on the media tool* being invoked.> > Thus receivers of session descriptions should be configurable in> > their interpretation of session descriptions in general and of> > attributes in particular.> >> > In RFC3264, it just restrict the "m=" lines, no evident restrict about> > "a=" lines:> > Because of these requirements, the number of "m=" lines in a stream never> > decreases, but either stays the same or increases.> >> > So, it is possible to define a=" line that means no change while absent> > in subsequent Offer/Answer.> > It is useful for rich and complex media types which need much more> > attributes to describe in the future.> >> > In the situation mentioned above, the subsequent Offer/Answer is just> > adjustment of session state. And> > *the modification can not be processed without the previous session> > state as the base.*(It is> > reasonablely to find in RFC3264 that: It is assumed that the higher> > layer protocol provides maintenance> > of some kind of context which *allows the various SDP exchanges to be> > associated together*.)> >> > After failure of Re-INVTE, it is still important for the two peers have> > the same point of view of session> > state, beacause that's the base of further modification if using the> > type of "a=" lines mentioned above.> >> > So, we can see that, "manual rollback" using a new Re-INVITE may refresh> > the session state, but may be no> > effective in the furure.> >> > In session usage such as remote virtual reality that makes the sense of> > physical immersion, it may be need> > many attributes of such media type. And it may weaken the real time> > sense while modify session with all> > the attributes list.> > So, it is practical to omit the attributes without adjustment in SDP.> >> > --------------------------------------------------------> > 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
