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

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

 



 
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: 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
& gt; > To: gao.yang2@xxxxxxxxxx; shin@xxxxxxxxxxxxxxx
> > CC: sipping@xxxxxxxx; gonzalo.camarillo@xxxxxxxxxxxx
> > Subject: Re: 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: 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) | au dio1
> > (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 addr essed. 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>
>



更多热辣资讯尽在新版MSN首页! 立刻访问!
_______________________________________________
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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux