- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 14 Jan 2014 08:29:04 +0100
- To: "piranna@gmail.com" <piranna@gmail.com>
- CC: public-webrtc <public-webrtc@w3.org>, Luis López Fernández <luis.lopez@urjc.es>
On 2014-01-13 22:28, piranna@gmail.com wrote: >>> (third bullet) I would suggest using the open event on the creating side for >>> this. You get the channel from the target property of the event, and the >>> channel is in the open state; same state as in the "datachannel" event >>> handler on the receiving side. >>> > I've re-read about this point on the latest specification (10 > September 2013) and if I understood it correctly, it's not defined to > work as you said: > > " > A RTCDataChannel, created with createDataChannel() or dispatched via a > RTCDataChannelEvent, MUST initially be in the connecting state. When > the RTCDataChannel object’s underlying data transport is ready, the > user agent MUST announce the RTCDataChannel as open. > > When the user agent is to announce a RTCDataChannel as open, the user > agent MUST queue a task to run the following steps: > > If the associated RTCPeerConnection object's RTCPeerConnection > signalingState is closed, abort these steps. > > Let channel be the RTCDataChannel object to be announced. > > Set channel's readyState attribute to open. > > Fire a simple event named open at channel. > > When an underlying data transport is to be announced (the other peer > created a channel with negotiated unset or set to false), the user > agent of the peer that did not initiate the creation process MUST > queue a task to run the following steps: > > If the associated RTCPeerConnection object's RTCPeerConnection > signalingState is closed, abort these steps. > > Let channel be a newly created RTCDataChannel object. > > Let configuration be an information bundle received from the other > peer as a part of the process to establish the underlying data channel > described by the WebRTC DataChannel Protocol specification. > > Initialize channel's label, ordered, maxRetransmitTime, > maxRetransmits, protocol, negotiated and id attributes to their > corresponding values in configuration. > > Set channel's readyState attribute to connecting. > > Fire a datachannel event named datachannel with channel at the > RTCPeerConnection object. > " > > If I understood it correctly, 'datachannel' event is dispatched on the > receiver endpoint to notify that a new DataChannel has been created, > but it's on the 'connecting' state, not the 'open' one, and that the > 'open' event should be dispatched on both endpoints (starter and > receiver) when the connection is ready and not only on the starter > one. Is it correct? If so, I don't see any problem to also dispatch > the PeerConnection 'datachannel' event on the starter endpoint, since > definitely it's not doing the same task that the DataChannel 'open' > one... Your interpretation is correct. We switched to the "open on both sides" approach a while ago. But then there you have your symmetric event; if you need to do similar work on both sides as the result of a event, can't you use the open event? Generally it's much more convenient to work with synchronous APIs than with events and callbacks. Since createDataChannel() is a factory method that can be synchronous, I think it's more intuitive to keep it like that. /Adam
Received on Tuesday, 14 January 2014 07:29:28 UTC