Re: [rtcweb] Data Channel Negotiation

Michael Tuexen <> Mon, 11 February 2013 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9166D21F86C4 for <>; Mon, 11 Feb 2013 12:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jD75OzTA0iTm for <>; Mon, 11 Feb 2013 12:04:49 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 7AAC621F86CD for <>; Mon, 11 Feb 2013 12:04:48 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id B15331C0C0695; Mon, 11 Feb 2013 21:04:28 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tuexen <>
In-Reply-To: <>
Date: Mon, 11 Feb 2013 21:04:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup <>, "" <>
Subject: Re: [rtcweb] Data Channel Negotiation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Feb 2013 20:04:49 -0000

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

> On 9 February 2013 07:24, Randell Jesup <> 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
> 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