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

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

 




I think so now. And you can ask Gonzalo if he think it is the only branching.

But I want to know that if I or someone else find new branching, can it be talked?




"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>

2009-03-02 15:00

收件人
<gao.yang2@xxxxxxxxxx>
抄送
"Gonzalo Camarillo" <gonzalo.camarillo@xxxxxxxxxxxx>, "Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx>, "sipping" <sipping@xxxxxxxx>, <sipping-bounces@xxxxxxxx>
主题
RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?






>>Then that is: Considering RFCs, "refine codecs" is "a new modification".
>>                
>>Not considering "evolution and extension", it is still a solution without any violation of RFCs.
>
>Yes, but that was not the point. I am trying to figure out what the differences between the proposals are.
>
>[Gao] Yes.
>
>But what I think important for "evolution and extension" is nested transaction. And if using something like "a= chain"(RFC3108) in Offer/Answer, nested transaction concept can be more
>effective.

Yes, but we can have "something likes" - we need clear rules.

>So, again: is the "late commitment" currently the ONLY difference between yours and Gonzalo's proposals, or is there something else?
>
>[Gao] IMO, "Late commitment" is the most important branching for current SIP/SDP usage.

That is not what I asked.

Regards,

Christer



               
               
               
               
               
               "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>

               2009-03-02 14:21

                               
                                收件人
                                <gao.yang2@xxxxxxxxxx>
                                抄送
                                "Gonzalo Camarillo" <gonzalo.camarillo@xxxxxxxxxxxx>, "Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx>, "sipping" <sipping@xxxxxxxx>, <sipping-bounces@xxxxxxxx>
                                主题
                                RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

                               




               Hi,
                 
               Again, I strongly do NOT think we should choose an "evolution and extension" approach, and let organizations decide what is a new modification, and what isn't. Again, you can have entities which belong to DIFFERENT organizations´communicating with each other, and those should have a common understanding of the rules.
                 
               If you have a closed network, where you know that every entity belongs to a single organization, you can of course do whatever you want. But, in that case you don't need to standardize it.
                 
               Regards,
                 
               Christer
               
               
________________________________

               From: gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx]
               Sent: 2. maaliskuuta 2009 5:47
               To: Christer Holmberg
               Cc: Gonzalo Camarillo; Hadriel Kaplan; sipping; sipping-bounces@xxxxxxxx
               Subject: 答复: Re: [Sipping] Summary of Closing the offer/answer rollback issue?
               
               
               My draft is open for evolution and extension. My view is that:
               
               Considering RFCs, "refine codecs" is "a new modification". And if some one(org/operator/internal usage) think "refine codecs" is part of the original modification. It still can assure its session state by nested transaction concept.
               
               Some custom-built one really treated it as part of the original modification.
               
               
               
               
               "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>
               发件人:  sipping-bounces@xxxxxxxx

               2009-03-02 05:30

                               
               
                                收件人
                                "Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx>, "Gonzalo Camarillo" <gonzalo.camarillo@xxxxxxxxxxxx>, "sipping" <sipping@xxxxxxxx>
                                抄送
                               
                                主题
                                Re: [Sipping] Summary of Closing the offer/answer rollback issue?


                               


               
               
               
               
               Hi Hadriel,
               
               I guess Gonzalo will provide his summary soon, but I don't think there
               is currently a disagreement regarding pre-conditions. You call them
               "conditional offers", Gao calls them "notifications", but that's just
               wording... :)
               
               I think the one of the main issues at the moment is what happens after
               preconditions have been met on both sides:
               
               1) Is the change now commited/in-use, and a re-INVITE failure would not
               change that?                                       <----- "in-use"
               alternative
               
               OR
               
               2) Would a re-INVITE failure cause a fallback (this is what is meant by
               "late commitment")?                                <---- "late
               commitment" alternative
               
               
               If preconditions have NOT been met, and the re-INVITE fails, I think
               most agree that there will be a rollback to the "last committed state".
               
               
               Gao's draft also talk about other changes which would not be considered
               as "real" SDP offers, for example if you reduce codecs. But, at least I
               strongly prefer NOT to go into such details, because that would for sure
               cause interop issues. I am not sure what Gao's view on that is at the
               moment, though?
               
               
               Regarding the race condition, I think we can avoid that with some BCP-
               and guidance text.
               
               
               Regards,
               
               Christer
               
               
               
               -----Original Message-----
               From: Hadriel Kaplan [mailto:HKaplan@xxxxxxxxxxxxxx]
               Sent: Saturday, February 28, 2009 5:26 PM
               To: Christer Holmberg; Gonzalo Camarillo; sipping
               Subject: Summary of Closing the offer/answer rollback issue?
               
               
               Is there an email in this long thread that summarizes the issues?
               It's impossible to follow this thread. :)
               
               I'm not clear on what the issues are with pre-conditions that make
               failed offers concept break.  To me, pre-conditions are basically not
               real SDP offers; they're conditional offers.  Until the *all* the
               conditions are met, it's not "committed".  You continue using the last
               committed state.  I know there are race conditions, but considering how
               rare pre-conditions are in the real world (especially in re-Invite's),
               that I'm having trouble imagining why we should care about corner cases
               of such.  Regardless, I vote for any fixing that needs to happen because
               of pre-conditions should be around changing pre-condition logic, even if
               it means completely re-writing how pre-conditions works - don't change
               normal SIP or SDP. (not that anyone is proposing it, I just can't tell
               form this thread)
               
               Re-Invites and SDP offer/answer have so many interop issues in the wild
               even without pre-conditions, that this whole thread scares me. :(
               
               -hadriel
               
               _______________________________________________
               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.
               
               
               
               --------------------------------------------------------
               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.
               





                --------------------------------------------------------
                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.
               



--------------------------------------------------------
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.

--------------------------------------------------------
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

[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