Re: [rtcweb] Data Channel Negotiation

[Michael Tuexen <[e-mail]>]

On Feb 11, 2013, at 8:54 PM, Martin Thomson wrote:

> 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?
One important thing is that they tie the two outgoing streams together.
Each side controls its outgoing streams.
The other things are just declaring channel properties...

Best regards
Michael
> 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.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>