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

Stefan Håkansson LK <> Tue, 19 February 2013 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1A2D21F8758 for <>; Tue, 19 Feb 2013 00:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.894
X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Npx14rwWTOLZ for <>; Tue, 19 Feb 2013 00:50:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 95C4D21F8726 for <>; Tue, 19 Feb 2013 00:50:15 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-4c-51233cc6e180
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 80.9F.10459.6CC33215; Tue, 19 Feb 2013 09:50:14 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 19 Feb 2013 09:50:14 +0100
Message-ID: <>
Date: Tue, 19 Feb 2013 09:50:14 +0100
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje4xG+VAg7u3dS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvWPm1gKfohW9HxxbGDcKdjFyMkhIWAisfXvYTYIW0ziwr31 QDYXh5DASUaJ411rWCGctYwSSy6sAaviFdCW+H2gn6mLkYODRUBV4tNmf5Awm0CgxPX/v5hA bFGBKIn3V5uYIcoFJU7OfMICYosICEtsfdULViMs4Ckx5+ZRqGWr2SXOd/8ES3AK6Egc/98M ZjML2EpcmHOdBcKWl9j+dg7YUCEBXYl3r++xTmAUmIVkxywkLbOQtCxgZF7FyJ6bmJmTXm64 iREYZge3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGEOv 9Vvmf/qcK6+V9N5SYHPg4yNZ2xqinl1TEjlY1d+bsLnd5NovCdnSuM2Hw9keirBFX/T7NZ9n Xt7XezqeR3QkmySWL+qSv/ROakl9wrb2L1baisuXFzUln/pao8K/zqrlwsF15hdW1uvsDp73 6K+268a6PcWc63+fS156999JQxHnOF43DyWW4oxEQy3mouJEADiELcUBAgAA
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: Tue, 19 Feb 2013 08:50:16 -0000

On 2013-02-19 00:25, Paul Kyzivat wrote:
> 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 normal way for a web application to communicate with a server is 
using http. Recently, more optimized means have been defined, WebSocket 
and Server-Sent Events.

Of course you could terminate a rtcweb data channel in a server, but I'm 
not sure how much that really buys you over using WebSockets in practice 
(sure, WebSockets only support reliable delivery, so perhaps for low 
latency needs there could be a gain).

But that said, why couldn't the server do the same things the client 
would do in JS over the currently defined data channel if you really 
want to use the rtcweb data channel for client-server communication?

> 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
> browser.
> 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.
>      Thanks,
>      Paul
> _______________________________________________
> rtcweb mailing list