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

Paul Kyzivat <> Mon, 18 February 2013 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EACA621E8045 for <>; Mon, 18 Feb 2013 15:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.352
X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7+zTvcw2vM0l for <>; Mon, 18 Feb 2013 15:25:29 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id ED35921E808C for <>; Mon, 18 Feb 2013 15:25:26 -0800 (PST)
Received: from ([]) by with comcast id 1phK1l0041GhbT851zRSeZ; Mon, 18 Feb 2013 23:25:26 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 1zRS1l0023ZTu2S3TzRSJ6; Mon, 18 Feb 2013 23:25:26 +0000
Message-ID: <>
Date: Mon, 18 Feb 2013 18:25:25 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1361229926; bh=xygoI29qDl1oxfZpegpKLmGB71438gjyiFv9zwjwIh8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=W9tqTBytxMpmfPJzFFq6DAz8n+Ld4Hmtc4LCo0YUsW29n1s09u+kC4nipFVR6/uBq nl6TtoRLgN2WVrQv7IpnUTjjd1kDzDdM6ZZLslEba75ZqDCehMIJBELdFtIDrKI86C Fm/N3VTAhnbGQB2YZ94Jsh1CEp+i72xVXVDq1/uUTeyJfWjelClMlT39PA9vPSs3Of TVuwY2GqhRjBNp2Mo/dPHtVbD9FgS2S4Ut1GtYeLcIBoFmm9kJdUOIHzq6g9Zb+wp5 N+G7V1sdzAl927jCpc8qY38T5awjwtECmVuX9icHxrwN75fsSN0bQGRCG2TIwww11l hPooLfaf9lKsg==
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: Mon, 18 Feb 2013 23:25:30 -0000

On 2/18/13 6:45 AM, Tim Panton wrote:
> On 15 Feb 2013, at 21:15, Martin Thomson wrote:
>> On 15 February 2013 12:55, Michael Tuexen
>> <> wrote:
>>> I think I understand what you are proposing. But what happens, if
>>> both sides at about the same time open want to open a data channel.
>>> For both sides outgoing stream X is free, so they use this. So the
>>> endpoints end up with one data channel instead of two.
>> Actually, I'd go further than that.  I'd require that browser
>> implement the same algorithm for selecting the stream to use.  That
>> implies that in all cases other than the rarest race conditions, you
>> get the same data channel.
> I'd remind everyone that in the case of the data-channel there are _no_
> cases where the endpoints don't know what the other end is supposed to be doing.
> There are no statically programmed legacy devices which support the data channel.
> Endpoints can be assumed to be dynamic javascript clients programmed to interoperate with each other,
> most often with the same javascript loaded from the same source and sharing a signalling channel.

I disagree.

For the cases RTCWEB cares about, presumably at last one end is a 
javascript client. But the other end may not be. There can be many cases 
where one end is a server.

The case *I* care about right now is where one end is a CLUE server, and 
the other end is an RTCWEB browser client. CLUE needs a data channel, 
and we are aiming at one compatible with RTCWEB, in part precisely to 
make this case a possibility. And while RTCWEB doesn't care, CLUE wants 
to be able to use the same channel machinery with *neither* end is a 

Obviously this doesn't exist yet, so we are flexible about the details. 
But we need for it not to depend on being javascript to javascript.