Re: [rtcweb] Data Channel Negotiation

Martin Thomson <> Fri, 08 February 2013 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CE1521F8795 for <>; Fri, 8 Feb 2013 01:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yZTar5f5U7pg for <>; Fri, 8 Feb 2013 01:21:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 36D7121F874F for <>; Fri, 8 Feb 2013 01:21:49 -0800 (PST)
Received: by with SMTP id ez12so558958wid.6 for <>; Fri, 08 Feb 2013 01:21:48 -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=l9eBGxxzwFxml/IDOCsuQuZ/U0HLkoXMmw1BYc2fN/c=; b=VtZFf6t7kv6gH+9exXfklGbtPYLNm6AimzIW9+5QyYTg3Jg/d2IoYPSCflc9XUghOL LudBXMBcwHEFp2cMGUbeEOLGZP2hrgrRaiMuCy52d3Wcv5mE0iIXIJvoxPZrDvzcmzB+ V6jAmxfvoI6ozi9PzTciHgGfC7pYOXGGQs3n6bQLb49lAQUJJ3VyZQALLKa8WrUuXc5j iu2LOLQRxqcR8Ch1IEMH9UoFn5j0vAW756K8I3dhEKUSfdKJ2Gf/EYtp7Lx66XFZHzSS p/dFnzzgWPG3VjF3ijPICOfAlXrx3YKscuCg/bAWgOrSU1NLtKSgHYjx7wB6YDPTs+ii GVRg==
MIME-Version: 1.0
X-Received: by with SMTP id dl6mr1073789wib.9.1360315308180; Fri, 08 Feb 2013 01:21:48 -0800 (PST)
Received: by with HTTP; Fri, 8 Feb 2013 01:21:48 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 08 Feb 2013 04:21:48 -0500
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: Fri, 08 Feb 2013 09:21:55 -0000

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

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

> The practical limit is likely lower in that it returns a single
> arraybuffer/blob.  Right now Firefox limits Websockets to 2Gb.

This is definitely an implementation choice.  I expect lower limits in
many implementations.  Desktop browsers probably need to be a little
more flexible than most.

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