Re: [rtcweb] Data Channel Negotiation and reopening of decisions

Michael Tuexen <> Fri, 15 February 2013 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59C8A21F85B3 for <>; Fri, 15 Feb 2013 13:02:38 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 58MmzipjkPTn for <>; Fri, 15 Feb 2013 13:02:37 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 95ABB21F85B2 for <>; Fri, 15 Feb 2013 13:02:37 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 7E35F1C0C0693; Fri, 15 Feb 2013 22:02:36 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Tuexen <>
In-Reply-To: <>
Date: Fri, 15 Feb 2013 22:02:35 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Ted Hardie <>
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup <>, "" <>
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
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, 15 Feb 2013 21:02:38 -0000

On Feb 15, 2013, at 7:04 PM, Ted Hardie wrote:

> On Thu, Feb 14, 2013 at 6:59 PM, Michael Tuexen
> <> wrote:
>> I consider each side managing only its outgoing streams. Therefore if
>> each side opens a data channel at about the same time, you end up
>> with two data channels. Assume that there are no data channels before that
>> and that you don't reserve any stream, chances are that each data channel
>> consists of out going stream with stream id 0 and incoming stream with
>> stream id 1.
> Sorry for being dense, but if you get an INIT where the Stream
> Identifiers in the data
> chunk are already in use, why wouldn't you error out?  Alternatively,
Martin suggests to have no control protocol for opening data channels.
So there is nothing like an INIT message on a stream.
> can existing
> implementations keep that straight as a tuple of SCTP association,
> stream identifier?
> If the latter, then occasionally having two data channels instead of
> one does not
> seem to be that big a deal; am I missing something?
He would occasionally end up with one data channel instead of two.
Systems, not behaving as expected *occasionally*, is a bad thing for
me. I consider this a bug and it much harder to debug if it only
occurs occasionally. It is even worse, if the developer hasn't made
any mistake...

For me, it should be clear how a data channel is set up, used,
and teared down. Yes, things can go wrong on the wire (connection
drop or so), but the API provides error handling. But we shouldn't
come up with a solution which works most of the time. For specific
applications this might be most of the time or even always.

Best regards
> regards,
> Ted