Re: [rtcweb] Data Channel Negotiation

[Martin Thomson <[e-mail]>]

On 7 February 2013 10:49, Randell Jesup <[e-mail]> wrote:
> The proposal I made yesterday (though I really didn't get a chance to
> present it) was purely declarative in the SDP (the mixed case I proposed).
> They were stand-ins for the Open in-band messages and carried the same
> declarative info.

The difference, from what I saw, was that the declarations in your
examples showed stream 1 in the offer and no stream 1 in the answer.
This would require that stream 1 appear in the answer with the
attributes that the answerer had assigned (which we would require to
be the same as the offerer, unless the answerer side had already had
created a DataChannel).

> This limit probably can be relaxed; Websockets allows IIRC 71-bit lengths
> ...  just in case you need them.

63 bit.  A poor decision in my opinion, but we need to respect working
group consensus.

> The practical limit is likely lower in that it returns a single
> arraybuffer/blob.  Right now Firefox limits Websockets to 2Gb.

This is definitely an implementation choice.  I expect lower limits in
many implementations.  Desktop browsers probably need to be a little
more flexible than most.

> I like (a lot) the declarative approach, and all the complications were due
> to needing to fulfill glare considerations (now resolved by not requiring
> resolving of label glare and not requiring bidirectional stream pairs have
> the same number), and due to the requirement for websockets compatibility
> with onOpen (and to not fire it until you have positive notification from
> the other side). If you drop that last part, you have immediate declarative
> 0-RTT opening time DataChannels.  I would propose keeping things simpler for
> users and to use the wireline protocol for the declaration/response, and
> avoid all the weirdnesses around labels, protocols and modes caused by
> dropping it.
>
> I like your Layer 2, but with the wireline protocol previously speced.  It
> gets you all the label/mode/etc sync stuff, and merely rules out option A
> (or requires you to dedicate a control stream).

If we have out-of-band negotiation, the only thing that the protocol
needs is a type indicator (one bit).  Reserve the other 7 bits (or 254
values) and we're done.  There is no benefit to the control messages.