hi：
> signaling | O/A state (no precondition)
> ---------------------+----------------------------
> init-INVITE/200/ACK | audio1
> re-INVITE/183-rel | audio2
> PRACK/200OK | audio2 +video1
> UPDATE/200OK | audio3 +video1
> UPDATE/200OK | audio3 +video2
> UPDATE/200OK | audio4 +video2
> UPDATE/200OK | audio4 +video3
> UPDATE/200OK | audio5 +video3
> UPDATE/200OK | audio6 +video4
>
> Which is a part of the original modification ?
> Which is new modification ?
> Is the decision depend on preconditions ?
The differents between original modification and new modification
is that whether the state committed by the negotiation should be
rollback.
If UPDATE/200 is a new modification nested in re-INVITE,when re-INVITE
fails, the state committed by UPDATE/200 should be remained, but if
UPDATE/200 is an origianl modification nested in re-INVITE,when re-INVITE
fails, the state committed by UPDATE/200 should rollback.
And the definitions of the two should be defined clear further.
IMO, pre-conditions is original modifications.
Others, if "refine codec", it should be discussed further whether it's
an original modification, else, it's new modification.
Eric
sipping-bounces@xxxxxxxx 写于 2009-03-03 00:31:22:
> 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 | audio1
> re-INVITE/183-rel | audio2
> PRACK/200OK | audio2 +video1
> UPDATE/200OK | audio3 +video1
> UPDATE/200OK | audio3 +video2
> UPDATE/200OK | audio4 +video2
> UPDATE/200OK | audio4 +video3
> UPDATE/200OK | audio5 +video3
> UPDATE/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: [Sipping] 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/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.
_______________________________________________ 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
