[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] Summary of Closing the offer/answer rollback issue?



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