- From: Li Li <Li.NJ.Li@huawei.com>
- Date: Fri, 14 Sep 2012 20:19:49 +0000
- To: Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <B60F8F444AAC9C49A9EF0D12D05E0942216C3A13@szxeml535-mbx.china.huawei.com>
Justin, Thanks for the proposal. When I read transitions as defining all permitted operations from each state, I have a few questions about the peer connection state machine. According to the state machine, after you call pc.setLocal (Offer1), you can’t call pc.setRemote (Offer2). Is this true? If so, what happens if pc.setLocal (Offer1); // send Offer1 to peer // receive Offer2 from peer which beats Offer1 // not allowed: pc.setLocal(Offer2); On the other hand, the state machine allows me to call pc.setRemote(Offer) after pc.setRemote(Answer), and pc.setLocal(Offer) after pc.setLocal(Answer). Obviously, these sequences should not be allowed on a peer connection. It seems there should be two branching state machines, one for each side. The “Sent X” names are a bit confusing to me too. For example, the transition “New -> pc.setLocal(Offer) -> Sent Offer” suggests that Offer has been sent after the call, but I can call pc.setLocal(Offer) before sending Offer to peer. Thanks, Li From: Justin Uberti [mailto:juberti@google.com] Sent: Monday, September 10, 2012 2:26 AM To: Cullen Jennings (fluffy) Cc: public-webrtc@w3.org Subject: Re: Phone call about ICE states I updated my IceState proposal (which corresponds to Option A, or the high-level part of Option C) based on the points raised at Thursday's discussions. Please take a look at the "IceState proposal" section in the attached document, and let me know what you think. On Thu, Sep 6, 2012 at 7:55 AM, Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote: Updated slides with Justin Option C added ..
Received on Friday, 14 September 2012 20:20:35 UTC