On 5/14/13 13:39, Martin Thomson wrote: > On 14 May 2013 10:30, Adam Roach <adam@nostrum.com> wrote: >> On 5/14/13 12:20, Martin Thomson wrote: >>> On 14 May 2013 07:33, Eric Rescorla <ekr@rtfm.com> wrote: >>>> FWIW, I my vote is that the state change at the time that the callback >>>> fires. >>> I agree, but you could be more precise. A state change should happen >>> when the actions associated with set(Local|Remote)Description are >>> complete. >> And successful. > I'm not sure, but I think that state transitions might be unavoidable > as a result of certain failures. > Right. But that's not what I meant. The problem with the current spec is that the state transitions are all worded in a way that assumes success. Look at Jan-Ivar's example: have-local-offer A local description, of type "offer", has been supplied. That's an extremely naïve way of describing it, since it presumes that the SDP is valid and that the PeerConnection signaling state machine was in a state for which supplying local offer made sense. (Alternately, on its face, it means that the state changes to "have-local-offer" regardless of whether the offer was valid or whether it made any sense to supply it). So, when I said "and successful," what I really meant was that it would be far clearer to say something like: have-local-offer A local description, of type "offer", has been successfully applied. Obviously, failures can make the state transition in other ways, but that's not what I was referring to above. /aReceived on Tuesday, 14 May 2013 18:59:44 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:43 UTC