- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 20 May 2013 13:50:51 +0200
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- CC: public-webrtc@w3.org
On 2013-05-11 16:35, Jan-Ivar Bruaroey 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 > 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 > 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. ? This is described in detail by the set local/remote processing model [1]. It says that the signalingstatechange event should be fired in a task that is queued. /Adam [1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#set-description-model
Received on Monday, 20 May 2013 11:51:19 UTC