Re: Fwd: Re: SCTP mapping to data channels

On 2/6/2012 10:06 AM, Harald Alvestrand wrote:
> On 02/05/2012 11:25 PM, Stefan Hakansson LK 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.

Right, so that's good.

I wrote:
>>> 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).

Justin wrote:
>>> 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.

Yes, but then we'd need to include some type of in-stream demultiplexer 
to demux back into the JS-level data channels; there's a big plus to a 
1-1 mapping (also for onopen and onremove events).

SCTP has per-DATA options, but we're only exposing per-dataChannel 
options.  If we need to transfer the info at channel open time, I'd 
really look at the PPID stuff to transfer the type of dataChannel 
immediately on open (before first data packet).  I'm still not certain 
we need that; we need to look more at what the implications for the JS 
API are.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 6 February 2012 15:56:57 UTC