- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 06 Feb 2012 07:06:30 -0800
- To: public-webrtc@w3.org
On 02/05/2012 11:25 PM, Stefan Hakansson LK wrote: > On 02/06/2012 05:51 AM, Justin Uberti wrote: >> >> >> On Sat, Feb 4, 2012 at 11:39 PM, Randell Jesup <randell-ietf@jesup.org >> <mailto:randell-ietf@jesup.org>> wrote: >> >> On 2/4/2012 3:43 PM, Harald Alvestrand wrote: >> >> just my $0.02 off the cuff.... >> >> since the streams are naturally unidirectional, have no open, >> but do >> have a reset, it seems to me like we should reflect that unless >> we have >> a reason not to: >> >> - SDP item (TBD) is used to say "we want a data channel", and >> the >> initial max # of channels >> >> >> I'm not even sure we need that. The association can be created >> on-demand; we already have the DTLS connection. Initial channels is >> only marginally useful, and could be a simple attribute. >> >> >> Correct, if we're using BUNDLE, but I don't think BUNDLE is mandatory to >> use. >> >> >> >> - createDataChannel() grabs the first unused channel, adds more >> channels >> if it needs to >> >> >> Sure. >> >> >> - 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. > ondata should be named onmessage to be aligned with other APIs, and > (naturally) fires at the receiving end. Of course. > >> - a reset causes an onclose() event >> >> >> I'll need to check if reset is signaled to the far side immediately; >> I suspect it might not be. If it is, that would work. >> >> >> This sounds like a good way of handling construction/destruction of >> channels. > > I think we need some kind of "ack" from the receiving PeerCOnnection > that the dataChannel (I mean the particular channel created with this > createDataChannel) has been set up. Only when the ack has been > received (and the other end has crated the JS object that will receive > messages) should the onopen event fire (at the sending side). > >> >> >> >> With this we should not need any signalling (leaving apps to use >> channel >> 0 specially if they want to), and will in practice have an >> infinite >> number of channels. >> >> when in doubt, keep it simple.... >> >> >> Definitely. And this is a straightforward mapping, since we now >> know that adding channels and reset are supported. That simplifies >> our work (as does leaving them unidirectional - no glare, no params >> that need to be exchanged, etc). >> >> There is an assumption that for unreliable, partly-reliable and >> out-of-order channels that the receiver knows this fact; if not that >> would need to be exchanged (perhaps by the app on channel 0). >> >> >> This is kind of a tricky situation since as you point out, the >> reliable/in-order attributes are per-DATA, not per-stream. So we either >> need to surface this information per-packet, or disallow certain SCTP >> protocol usages (i.e. for endpoints that are not implemented using this >> API). an obscurantist mechanism would be to create new data channels for each combination of parameters we want to support, and an accessor to find the underlying SCTP channel number for each (for those who need that). This way, reliable, sequenced datagrams would be on one channel; unreliable, unsequenced ones would be on another, giving consistency.
Received on Monday, 6 February 2012 15:10:46 UTC