Re: [rtcweb] Data Channel Negotiation

[Martin Thomson <[e-mail]>]

On 9 February 2013 07:24, Randell Jesup <[e-mail]> wrote:
> As I mentioned, it was purely declarative (no response/negotiation), which
> is why the return SDP doesn't have them.

Your examples didn't have the values for stream 1 echoed in the
answer, so I assumed that it was "semi-declarative" or something like
that: where the values for stream 1 were inferred.

> If you were to extend this to work for renegotiations where glare is
> possible, you'd have to either wait for the renegotiation to finish, or use
> some even/odd sort of trick which was proposed way back when on the list.

If you want to resolve glare, then you use the mechanisms you already
have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
uses a fairly heavy-weight mechanism.  Keep in mind that you already
need this if you are using offer-answer.  Use whatever mechanism you
already have in place (I like the tie-breaker random number method
myself).

Or, you could stop worrying about glare and in those cases where glare
is possible, allow the collision to proceed.

This is an application choice.
> Out-of-band negotiation means either:
>
> a) SDP offer/answer (which in many cases will go via a central server,
> though it can go over an existing datachannel), min 1 RTT (perhaps
> 1-RTT-through-server) plus SDP processing delay, and requires implementing
> error handling for cases where the answers and offers don't properly match
> up,

This was my thought.  There is no need to reserve a channel for this
purpose, that's just extra machinery.  Any app that wants the fast
path for this will make their own.  And, the nice thing about that is
that they can do this before setting up the session.

> Are there real usecases where the in-band Open and OpenResponse messages
> actually cause a usecase not to work?

Well, given that we need message type stuff, we already have to suffer
some extra muck on top of the SCTP association.  Not many applications
will survive that.

No, the real question is: what value do these messages actually add?
What information do they convey that isn't already negotiated through
other channels?

Starting a stream with a header that declares attributes for a stream
sounds nice, but it's completely unnecessary in a vast number of
cases.  For many cases, this is a case of the same piece of software
talking to itself - it hardly cares.  In many other cases, negotiation
of properties through SDP is perfectly sufficient.

The only case I see for an in-band protocol is where you wish to
invent some new protocol on this platform, and I can't really muster
up that much enthusiasm for that.  It's far too heavily reliant on my
imagination.  Even in those cases, my knowledge of existing SCTP usage
patterns suggest that the properties that are sent in
Open/OpenResponse messages are not that useful to have.  Many
applications will use the same values for all new streams.