Re: [rtcweb] Data Channel Negotiation

Martin Thomson <> Mon, 11 February 2013 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 255AF21F8799 for <>; Mon, 11 Feb 2013 11:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.97
X-Spam-Status: No, score=-4.97 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eTgKNSNRT6ab for <>; Mon, 11 Feb 2013 11:54:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4F8D321F85E0 for <>; Mon, 11 Feb 2013 11:54:01 -0800 (PST)
Received: by with SMTP id hn17so3588616wib.16 for <>; Mon, 11 Feb 2013 11:54:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9MeTzL8+voaR0pz/cur4DzLUyZw3gxkETcSZ9bExw0o=; b=oViz9iFgelZ07pJiDdRfObyF9VM+AhvtBAsdog63j04g8/x1AFakSvcCit5vPBXKdm uxC0kN8arsRpx1PlkDcQaLOj9NhzZInziuIx2GZscX4arayPzmCL9TNQnSCaWayBi01Q TKVwokSFfCsiQh1oVwccO2jRMzvPGTHLke+4Rn8M4yUA2rrxPAeXKCSrZdLXvbCPRT6L 6xpt7zO4B10NQI8+E0jq2McbJ40Jy2RRYGS4YyawiXsrLRCk611Jra7QkQeDJk7YxCDO V3dcavjhDZ4DBQfa2m22+nvQhRFSos1pClP4DxaD/jq58b899eemlJy0CU41PtfK68sV cM3A==
MIME-Version: 1.0
X-Received: by with SMTP id bi10mr26402843wjb.5.1360612440484; Mon, 11 Feb 2013 11:54:00 -0800 (PST)
Received: by with HTTP; Mon, 11 Feb 2013 11:54:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 11 Feb 2013 11:54:00 -0800
Message-ID: <>
From: Martin Thomson <>
To: Randell Jesup <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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 19:54:02 -0000

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

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.