- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 07 Feb 2012 04:56:26 -0500
- To: public-webrtc@w3.org
On 2/6/2012 11:28 AM, Stefan Hakansson LK wrote: > On 02/06/2012 04:06 PM, Harald Alvestrand wrote: >>>> - channels are unidirectional >>>> - first packet (sequence #0) causes an onopen() event before the >>>> ondata() event >>> onopen fires at the sending PeerConnection, right? >> wrote this without looking up other text. the callback that fires when a >> new datachannel is added at the receiving end. There has to be one, or >> the receiving end will never know. > > I think what the receiving end would get is an dataChannelReceiveObject > (name to be changed!) when a new data channel is set up (in the same way > as the receiving end gets a new MediaStream object when adding media > streams), and I see no need for teh receiver to get info when the > channel is open, when data is received (by onmessage events firing on > the dataChannelReceiveObject) it is received. Sorry, yes, that would seem reasonable. The app would get an onaddstream, and the stream would be a dataChannel (though this requires some rework/base-classing/etc). Or we add an onadddatachannel (why are these all-lowercase?) for the receive side to make things easier for the app. > The sender side may on the other hand need to know when the data channel > is ready to use (open). Two things I can think of can hold up being able to do Send(): 1) association creation Could be avoided by either: a) signaling use of a data channel or b) creating one at call start time always, assuming we don't need to re-create one at IP address-change time. 2) increasing the number of channels (which would require a handshake I believe) You could always block on that (uh, no) or queue the data to go out when the channel opens instead of waiting for an onopen. However, the onopen would be totally local - no info from the other side needed. (We need to detail out how IP address changes will ripple through all this stuff - ICE, JSEP/etc, DTLS/etc, DTLS-STRP, data channels). -- Randell Jesup randell-ietf@jesup.org
Received on Tuesday, 7 February 2012 10:00:43 UTC