W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: Improvements suggestion for DataChannels

From: <piranna@gmail.com>
Date: Mon, 13 Jan 2014 22:28:27 +0100
Message-ID: <CAKfGGh3SiHi3Py_eEE8HLt3Wp6Qi_1LOdDKVB73rQdKYvBuSnQ@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: public-webrtc <public-webrtc@w3.org>, Luis López Fernández <luis.lopez@urjc.es>
>> (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...


-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Received on Monday, 13 January 2014 21:29:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC