Re: Is onsignalingstatechange synchronous?

FWIW, I my vote is that the state change at the time that the callback
fires.

-Ekr


On Sat, May 11, 2013 at 7:35 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> Hi everyone!
>
> I'm trying to recall if the point of the Boston interim rename of the
> signalingState states ("have-local-offer" etc.) was about simplifying the
> async question and merely fire onsignalingstatechange synchronously on
> function entry of functions like SetLocalDescription? I seem to read that
> into the language of the spec now as well, but it is not clear about it:
>
> http://dev.w3.org/2011/webrtc/**editor/webrtc.html#**rtcpeerstate-enum<http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcpeerstate-enum>explains "have-local-offer" this way:
>
>   "A local description, of type "offer", has been supplied."
>
> What is the definition of "has been supplied" here?
>
> http://dev.w3.org/2011/webrtc/**editor/webrtc.html#widl-**
> RTCPeerConnection-**onsignalingstatechange<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-onsignalingstatechange>says:
>
>   "This event handler, of event handler event type signalingstatechange,
> MUST be supported by all objects implementing the RTCPeerConnection
> interface. It is called any time the readyState changes, i.e., from a call
> to setLocalDescription, a call to setRemoteDescription, or code. It does
> not fire for the initial state change into new."
>
> When does a state "change, from a call to to setLocalDescription" et al. ?
>
> If anyone reading this over the weekend can recall and respond, that would
> be extra great as I'm hoping to have this implementation change in for
> Firefox 23's Monday deadline. Thanks! :-)
>
> ..: Jan-Ivar :.
>
>
>
>