Hi Paul, current B2BUAs already need to keep track of these things. Let's saythat instead of changing a codec an endpoint wants to change the UDPport for the stream subject to preconditions. If the B2BUA wants to beable to keep the right pin holes open and open new ones at the righttime, it needs to understand that the endpoints will be using their oldsession parameters until the preconditions are met. So, we are notimposing any new requirements on B2BUAs. Also, the state of the session can be derived from the signalling goingback and forth. That is, the B2BUA has all the information needed inorder to know which session parameters are currently being used. Cheers, Gonzalo Paul Kyzivat wrote:> Gonzalo,> > I think your proposal/concept about "in use" is interesting.> But is is it in fact the case that all involved parties agree on what> that is?> > I think this could especially be a problem for B2BUAs that don't> terminate media. Their *only* knowledge about the current state is what> they have learned from the signaling. Based on that they may have to> decide which SDP reflects what is currently "in use". But perhaps this> isn't really a problem and the B2BUA will simply discover the current> state later based on subsequent interactions with the two UAs.> > Also, "using" has two parts: "sending" and "receiving". There are> definitely windows during which one end is "sending" something but the> other side isn't "receiving" it yet.> > There are also those middleboxes that control "media gates" - only> letting media pass if the O/A conforms to their policies. Its unclear to> me how they are affected by this decision. But it could enhance the> difference between what one side is sending and the other side is receiving.> > Replying to Gao/Christer - I remain confused about what constitutes a> "new modification". I know there are sequences in use where the initial> exchange is done with a=inactive, and then another o/a is exchanged,> within the (re)INVITE to switch to a=sendrecv. Is that a "new> modification", or not?> > Thanks,> Paul> > Gonzalo Camarillo wrote:>> Hi,>>>> what I would like to know is if rolling back to the session state "in>> use" is an acceptable solution for you.>>>> Thanks,>>>> Gonzalo>>>>>> gao.yang2@xxxxxxxxxx wrote:>>> I think we are talking the same thing :).>>>>>> The main problem is What the session state is.>>>>>> Perhaps I said somthing on How to have a clear session state. I think >>> the two has correlation.>>>>>>>>>>>>>>> *Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>*>>>>>> 2009-02-26 21:30>>>>>> >>> 收件人>>> gao.yang2@xxxxxxxxxx>>> 抄送>>> sipping <sipping@xxxxxxxx>, sipping-bounces@xxxxxxxx>>> 主题>>> Re: 答复: Closing the offer/answer rollback issue>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi,>>>>>> > I think this problem is important. We should choose a right way for the>>> > future.>>>>>> yes, that is why we should make a decision, close it, and move forward.>>>>>> > Could we make the main proposal(such as mine and Christer Holmberg's) as>>> > a WG draft. I think it is important to let the people outside the>>> > SIPPING mail list to join in the disccussion, if they want. :)>>>>>> we already have a WG draft. What we are discussing here is how to close>>> an open issue within that draft. I made a concrete proposal on this>>> thread and asked for feedback on it. Please, focus on discussing that>>> point so that we can move forward. If you want to discuss different>>> issues, feel free to do it in a different thread.>>>>>> Thanks,>>>>>> Gonzalo>>>>>>>>> -------------------------------------------------------->>> 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 _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
