Re: [rtcweb] Data Channel Negotiation

Martin Thomson <> Mon, 11 February 2013 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20A9F21F8682 for <>; Mon, 11 Feb 2013 13:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ze5N9oMCkxxb for <>; Mon, 11 Feb 2013 13:43:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 35AEC21F8893 for <>; Mon, 11 Feb 2013 13:43:59 -0800 (PST)
Received: by with SMTP id hq4so3698969wib.12 for <>; Mon, 11 Feb 2013 13:43:58 -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=c3Ei2DILfB+QwTDL+vItArHelZwf5tOp4FboLdL6Ls4=; b=ohPoMQXYueP6sbvwayB0Hy/19uKSgaq5Qt7SO+MjyjOCXJKTuBdiaIYfVgmrCkRQFw x4dWsiRHaBlrPDvS3QvOuIrlsjUilVLFKhQWzkTBN619nVuYFPdnioVLKHT08LfyzvHa bVMNR3kI8wRiHdCTKtZQJWP5WlQJ8Dk8W5fqK8gJPV1Vs0ZHvE/yqbtcCeo1pb+c6pSy AtctSxNCi+8uNqdNwUgOVHJBS741g0GJnZzoIiiceVmx1zPW0BGcYTd4EAM4sqNkFbfG DPiXROtLTOs6s6zoe4oap2aEu6e5TB61vNfPUxrxyqDi+B27W7AIYp3wP2MvmkkLq5LY 3vBQ==
MIME-Version: 1.0
X-Received: by with SMTP id h5mr19699050wjw.21.1360619038398; Mon, 11 Feb 2013 13:43:58 -0800 (PST)
Received: by with HTTP; Mon, 11 Feb 2013 13:43:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 11 Feb 2013 13:43:58 -0800
Message-ID: <>
From: Martin Thomson <>
To: Michael Tuexen <>
Content-Type: text/plain; charset="UTF-8"
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 21:44:00 -0000

On 11 February 2013, Michael Tuexen <> wrote:
> 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...

The binding between stream X in one direction and stream X in the
other is as strong - or as loose - as the application needs.  This is
a departure from what was previously specified, but I think that the
advantages (0 RTT establishment) outweigh the disadvantages.

>>> How do you handle a shortage in the number of streams? How do you
>>> handle collisions if both sides want to open a data channel and
>>> chose the same streams?
>> A shortage is easy, createDataChannel can throw an exception.
>> Collisions are also easy - if you care about consistency, then do an
>> offer/answer, which has inbuilt glare resolution.  If you don't care
>> about consistency, both sides can create and use channels without
>> having to agree on the details.  (That's mostly based on the stuff
>> below.
> However, *if* data channels are bidirectional (which they currently are),
> then you need to tie two streams together. This has to be done somehow.
> I'm wondering how you envision this without using SDP and without the
> data channel protocol...

The easiest way to tie two channels together is to use the stream
number.  That is what I was proposing.

(If stream numbers are used, then you don't even need to have a strong
uniqueness guarantee on the label.)

In the case that this is negotiated, then the guarantee is exactly the
same as the one provided previously.  Otherwise, it's a little less
strong.  If both sides create a channel at the same time, then they
could be bound together without any strong assurances about the exact
nature of the bidirectionality guarantee.  Now, I'm OK with that.  You
may not be.

> If we change to data channels being uni-directional, then most of
> the stuff done by the data channel protocol is not required... I agree
> with that conclusion.
> However, currently that the bi-directional.

The API would remain bi-directional.  In fact, the API would be
unchanged, except as it pertains to timing of channel use.  The
guarantees with respect to consistency would be weaker than what is
provided, depending (again) on that timing.

> Instead of "prevent sending the return message" which would one side
> waiting forever,

That presumes a lot.  Many protocols have one-way messages.

> I would prefer sending some sort of error message
> (which is currently not specified enough in the data channel protocol).

This also assumes that you have some channel upon which to end this
error message, plus a definition for the error message.  I'm looking
to have less protocol machinery, not more.

>> number of channels to the lower of the two stream limits.  I prefer
>> the latter.
> As long as you know this limit... But RFC 6525 allows you to increase the
> number of streams (unless the peer agrees to do so).

Negotiating stream limits up doesn't seem like a particularly likely
thing in this sort of environment.  That said, we probably need to
decide if this is a feature that we want to have available.  If it is
available, then this could be used in the case that the limits are

>> b. There is no guarantee that the other side hasn't already created a
>> data channel on the same number.  That's not a problem - you just end
>> up with asymmetry.
> This is a normal case with the current data channel protocol. The
> stream identifiers might not be the same in both directions.
> When testing with the current implementation in Firefox, this actually
> happens a lot.

Interesting.  I'd be interested in learning how this would be signaled
and what the advantages of this arrangement are.