Gao I am confused about your explanation. Does "the suspending state" mean "preconditions are not met" ?What does "part of the original modification" mean ? signaling | O/A state (no precondition)---------------------+----------------------------init-INVITE/200/ACK | audio1re-INVITE/183-rel | audio2PRACK/200OK | audio2 +video1UPDATE/200OK | audio3 +video1UPDATE/200OK | audio3 +video2UPDATE/200OK | audio4 +video2UPDATE/200OK | audio4 +video3UPDATE/200OK | audio5 +video3UPDATE/200OK | audio6 +video4 Which is a part of the original modification ?Which is new modification ?Is the decision depend on preconditions ? Regards,Shinji >Comments inline.> >>> Subject: RE: Summary of Closing the offer/answer rollback issue?>> Date: Mon, 2 Mar 2009 14:45:10 +0100>> From: christer.holmberg@xxxxxxxxxxxx>> To: gao.yang.seu@xxxxxxxxxxx; gao.yang2@xxxxxxxxxx; shin@xxxxxxxxxxxxxxx>> CC: sipping@xxxxxxxx; gonzalo.camarillo@xxxxxxxxxxxx>> >> 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?>> >>[Gao] If all the Offer/Answer pairs during the suspending state are part of the original >modification, it is.>> >>But if there is a new modification, it is not.>>>> >> 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>> >> >>[Gao] If treat "refine codec" as part of the original modification, it is.>> >>>> >> 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: [Sipping] 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_______________________________________________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
