Re: [rtcweb] Data Channel Negotiation

Randell Jesup <> Sat, 09 February 2013 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81D4721F88E4 for <>; Sat, 9 Feb 2013 07:24:43 -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 p3lgLtO1BVz3 for <>; Sat, 9 Feb 2013 07:24:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C860921F85DA for <>; Sat, 9 Feb 2013 07:24:42 -0800 (PST)
Received: from ([]:58107 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1U4CIE-000Bgh-27 for; Sat, 09 Feb 2013 09:24:42 -0600
Message-ID: <>
Date: Sat, 09 Feb 2013 10:24:44 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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: Sat, 09 Feb 2013 15:24:43 -0000

On 2/8/2013 4:21 AM, Martin Thomson wrote:
> On 7 February 2013 10:49, Randell Jesup <> 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).

As I mentioned, it was purely declarative (no response/negotiation), 
which is why the return SDP doesn't have them.

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 

>> 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.

Ah yes, you're correct, 63 bits (encoded in 71 bits).  So small!

My proposal:
>> 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.

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,

b) a single control stream, which works, but it adds complexity since 
SCTP doesn't make between-stream guarantees about delivery, so you have 
to either have a handshake on the control stream before sending data (1 
RTT at least), or you need to have methods in place to handle 
out-of-order control versus data delivery, or

c) application-implemented out-of-band negotiation, which just (IMHO) 
pushes the problem off onto the application without solving any problems 
for the general case.  In the (fairly common) app talking to another 
instance of itself or a "known" peer, the application could pre-define 
what streams/channels mean, if we surface the stream numbers to the API 
(this would be far closer to the old 'raw SCTP' proposals, which push a 
lot over onto the app). This would also make interoperating in 
federation cases considerably more complex.

The reason the current in-band protocol uses in-stream open messages is 
that this avoids any out-of-order delivery issues (they're marked as 
reliable-in-order).  If you relax the don't-send-until-onopen JS 
requirement (which is no work for the wireline protocol; it's already 
supported) and fire onopen immediately on createDataChannel or when a 
channel open comes in, you have 0-RTT startup, and you retain all the 
symmetry, label, protocol, etc that had been previously agreed to.  See 
my quoted proposal above.

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

Randell Jesup