Re: [rtcweb] Data Channel Negotiation

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 348F721F8845 for <>; Mon, 11 Feb 2013 11:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.839
X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OJDhbNRzMZSE for <>; Mon, 11 Feb 2013 11:40:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5CCEC21F87C3 for <>; Mon, 11 Feb 2013 11:40:12 -0800 (PST)
Received: by with SMTP id e12so4920714wge.34 for <>; Mon, 11 Feb 2013 11:40:11 -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=zah9+3FssmdJx49N4H6IVp6lcfh8+hI3dVMXL0TzajE=; b=mMkBONjxtIFV2GKbUNsB9ZOBkVWlEmQl8E3XGxYlpdJ1kR9Gokwlp86RXqDrpsER4X rqxYX8ei7hIr36jGPDlciqr4d4WEh8iHABCzMzIh4pqOCTiwNzXtL9axN5QFjXo3AODv qSHU++GQv/X6w1bo0YxZ+7J+or5E54pYOITPaOuYVejXp0Z0OvUep9w/KPqxANSjzqF9 7b2M9WqupZiZcChuV8wuNTuuu0tX8irP99T2elJoMUpHrC7BYpRADOxc9BRGlwWyLQoO IdmK1bjHz6u0qLUsMB0rzbqJ7sYJ7W50jOJQWB0ir3UfngsMUH15mCQZsfBnP0LEbSAK xsag==
MIME-Version: 1.0
X-Received: by with SMTP id bw19mr18306260wib.28.1360611611456; Mon, 11 Feb 2013 11:40:11 -0800 (PST)
Received: by with HTTP; Mon, 11 Feb 2013 11:40:11 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 11 Feb 2013 11:40:11 -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 19:40:13 -0000

On 8 February 2013 09:43, Michael Tuexen
<> wrote:
>> Creating a new data channel triggers the onnegotiationneeded event.
> The signaling channel might have a different RTT than the peer to peer
> connections. So you prefer to do take always the signaling channel.

But since you have a short path for this, you can take that path.
Some people may prefer to take the slower signaling path for this, but
those that care about speed will use the data channel to do channel
establishment (and they will probably do what I suggest below).

> Taking down a data channel is not signaled via SDP, right?

I believe that you are able to use in-band mechanisms (6525) for take-down.

> 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

> There is also a limitation of lifetime in milli seconds.

Sure, let's have that too.  All this is per-message, so consistency
isn't really a required property.

> So basically a data channel is not symmetric anymore. Do you consider
> it bidirectional or unidirectional?

Yes.  Depending on the needs of your application.  Inherently, they
are unidirectional.  But if you care about the bidirectional property,
then you are free to perform a signaling negotiation to ensure
consistency (which is the only property that was provided by the
negotiation as designed previously).

>> Firstly, the arrival of a packet on a stream that is not negotiated
>> will require the creation of a data channel.  The properties of this
> If you consider a data channel to be bidirectional, what makes sure
> that a stream for the backwards direction is available? How do you
> now the pairing?

There is no guarantee.  Two reasons for this, neither of which I find
particularly dire:

a. I don't recall there being any signalling of the stream limit, so
there is a possibility that the stream limit in one direction will
exceed the limit in the other.  Streams with numbers that exceed the
lower limit will of course be unable to be reciprocal.  Two solutions
occur to me: 1. prevent the sending of return messages, or 2. cap the
number of channels to the lower of the two stream limits.  I prefer
the latter.

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.

Note: deferring the allocation of a stream number until messages are
sent on streams does allow the browser implementation some flexibility
in how it manages assignment of streams.

> Not sure why you refer to RFC 4920... RFC 4960 (SCTP) doesn't have such
> a limit.
Crossed wires :)