Re: Fwd: Re: SCTP mapping to data channels

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?
ondata should be named onmessage to be aligned with other APIs, and 
(naturally) fires at the receiving end.

>         - 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).
>
>
>
>
>
>     --
>     Randell Jesup
>     randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>
>
>

Received on Monday, 6 February 2012 09:14:27 UTC