[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sipping] 答复: Re: Summary of Closing the offer/answer rollback issue?
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 at ietf.org 写于 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 at ericsson.com
> >> To: gao.yang.seu at hotmail.com; gao.yang2 at zte.com.cn; shin at softfront.co.jp
> >> CC: sipping at ietf.org; gonzalo.camarillo at ericsson.com
> >>
> >> 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 at hotmail.com]
> >> Sent: 2. maaliskuuta 2009 15:32
> >> To: Christer Holmberg; gao.yang2 at zte.com.cn; shin at softfront.co.jp
> >> Cc: sipping at ietf.org; 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 at ericsson.com
> >> > To: gao.yang2 at zte.com.cn; shin at softfront.co.jp
> >> > CC: sipping at ietf.org; gonzalo.camarillo at ericsson.com
> >> > 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 at softfront.co.jp>
> >> >
> >> > 2009-03-02 17:43
> >> >
> >> >
> >> > 收件人
> >> > sipping <sipping at ietf.org>
> >> > 抄送
> >> > "Christer Holmberg" <christer.holmberg at ericsson.com>,
gao.
> yang2 at zte.com.cn, Gonzalo
> >> > Camarillo <gonzalo.camarillo at ericsson.com>
> >> > 主题
> >> > 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 at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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.