Hi, As we know, sometimes when you use preconditions you may do some modifications for a stream, in ADDITION to simply change the precondition status. I guess the most typical example is codec refine, ie you reduce the sets of codecs when it's know what both ends support. Wouldn't it be possible to say that whatever change is done for a stream, if the the re-INVITE fails before the preconditions have been met everything will be rolled back for that stream? So, if I send an UPDATE and remove a codec, while preconditions still haven't been met, that codec change would also be rolled back if the re-INVITE fails. SDP before re-INVITE audio-codec = 4 ----- re-INVITE audio-codec = 1,2,3 precon = not_met --- ><---- 18x audio-codec = 1,2,3 precon = not_met ---------- UPDATE audio-codec = 1 precon = not_met ----> //codec refine<---- 200 audio-codec = 1 precon = not_met ----- <---- 4xx -------------------------------------------------------------- SDP after re-INVITE audio-codec = 4 Regards, Christer ________________________________ From: gaoyang [mailto:gao.yang.seu@xxxxxxxxxxx] Sent: 2. maaliskuuta 2009 15:32 To: Christer Holmberg; gao.yang2@xxxxxxxxxx; shin@xxxxxxxxxxxxxxx Cc: sipping@xxxxxxxx; Gonzalo Camarillo Subject: RE: Summary of Closing the offer/answer rollback issue? 1. The question is same as asking whether "refine codec" is a new modification or just part of the original modification. By RFCs, it is a new modification. But I can not stop other people to treat as part of the original modification. If "refine codec" is a new modification by UPDATE/200OK, its commitment will go on and without rollback. If "refine codec" is part of the original modification, it will rollback for the faillure the original modification. Not matter by which point of view, the session state is all clear. 2. I have no right to decide it("refine codec") alone. If people want to reach a consensus to this point, we can talk further. If ask my personal view, I can accept: 2.1 treat it as new modification. or 2.2 treat it as part of the original modification, but "protected" by precondition. Why "protected" by precondition? By RFCs it is new modification at all, and as to make it part of the original modification, we should have semantics of suspending/resuming modification. How "protected" by precondition? We can define that only use "refine codec" in suspending state of QoS precondition. IMO, it is better to define a new precondition type for "refine codec". > Date: Mon, 2 Mar 2009 12:02:54 +0100 > From: christer.holmberg@xxxxxxxxxxxx > To: gao.yang2@xxxxxxxxxx; shin@xxxxxxxxxxxxxxx > CC: sipping@xxxxxxxx; gonzalo.camarillo@xxxxxxxxxxxx > Subject: Re: [Sipping] Summary of Closing the offer/answer rollback issue? > > > Hi, > > > >Explanation for Precondition notification > > > >Precondition notification can be treated as part of the original modification triggered by Re-INVITE. > > > >And only SDP with Precondition notification and without any other modification of session, during suspending state of session > >modification, is called precondition notification. > > So, what if I e.g. Also do a "codec refine" inside a precondition notficiation? > > Regards, > > Christer > > > > > > > > > > > > > OKUMURA Shinji <shin@xxxxxxxxxxxxxxx> > > 2009-03-02 17:43 > > > 收件人 > sipping <sipping@xxxxxxxx> > 抄送 > "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>, gao.yang2@xxxxxxxxxx, Gonzalo Camarillo <gonzalo.camarillo@xxxxxxxxxxxx> > 主题 > Re: [Sipping] Summary of Closing the offer/answer rollback issue? > > > > > > > Hi, > > The following table describes my understanding. > Is this right? > > signaling | O/A state | media in use > ---------------------+--------------------------------+-------------- > init-INVITE/200/ACK | audio1(met) | audio1 > re-INVITE/183-rel | audio2(notmet) | audio1 > (PRACK/200OK) | audio2(met) +video1(notmet) | audio2 > UPDATE/200OK | audio2(met) +video1(met) | audio2+video1 > UPDATE/200OK | audio2(met) +video2(notm et) | audio2+video1 > 4xx/ACK | | > Gonzalo's proposal | audio2 +video1 | > Gao's proposal | audio1 +video1(?) | > > > Regards, > Shinji > > > > -------------------------------------------------------- > 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. > < BR>> > _______________________________________________ > 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 ________________________________ 微软地图实时路况，为您节省的不仅仅是时间！ 立即查看！ <http://ditu.live.com/default.aspx?v=2&form=MICHAJ&cp=qcbgzzsz1gzz&style=r&lvl=4&tilt=-90&dir=0&alt=-1000&phx=0&phy=0&phscl=1&trfc=1&encType=1> _______________________________________________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
