Re: Fwd: Re: SCTP mapping to data channels

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.

> - 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
> - 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.

> 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).


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Sunday, 5 February 2012 04:41:09 UTC