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

Harald Alvestrand <> Wed, 20 February 2013 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1525E21F86CB for <>; Wed, 20 Feb 2013 11:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.407
X-Spam-Status: No, score=-110.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5P10K5lBk0F4 for <>; Wed, 20 Feb 2013 11:40:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C52BB21E8030 for <>; Wed, 20 Feb 2013 11:40:26 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73D6039E15B for <>; Wed, 20 Feb 2013 20:40:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7tQo4tVFtTMM for <>; Wed, 20 Feb 2013 20:40:22 +0100 (CET)
Received: from (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by (Postfix) with ESMTPSA id 2DF4B39E0CE for <>; Wed, 20 Feb 2013 20:40:22 +0100 (CET)
Message-ID: <>
Date: Wed, 20 Feb 2013 20:40:20 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 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: 8bit
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: Wed, 20 Feb 2013 19:40:28 -0000

On 02/20/2013 08:32 PM, Paul Kyzivat wrote:
> On 2/19/13 3:50 AM, Stefan Håkansson LK wrote:
>> 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 am thinking about is CLUE.
> Ignoring RTCWEB, a clue session is a specialized sip session.
> There could be two endpoints connected by SIP, or there could be two 
> or more endpoints in a star configuration with an MCU, each having a 
> SIP session.
> Those sessions, endpoint-endpoint, or endpoint-mcu, need clue-specific 
> data channel.
> Now lets introduce RTCWEB into that picture. For simplicity, lets just 
> consider the MCU case, where *one* of the endpoints is a browser. How 
> will that work?
> Clearly there must be a web server, that is only needed for the RTCWEB 
> endpoints. It may or may not be collocated with the MCU.
> Then we have two choices:
> 1) we implement clue endpoint code in javascript to run in the 
> browser. The webserver acts as a source of the javascript, and as a 
> gateway to sip. The javascript implements the clue protocol over the 
> data channel, selects and establishes media streams, etc.
> 2) we implement clue endpoint code in the webserver on behalf of the 
> endpoint. It implements the the clue protocol over a data channel, 
> etc. It then uses proprietary signaling between itself and the browser 
> to manipulate all the streams and displays.
> I see (1) as the preferred path. IIUC what you are suggesting looks 
> more like (2). In (2) the web server must be much more knowledgeable 
> about CLUE. It also could be slow if things start happening in the 
> data channel that must be mapped to http to be communicated to the 
> browser.

I would think that in the 2) case, "the webserver" would be "a gateway 
media server". There's absolutely no reason I can think of to colocate 
the webserver with the gateway media server.

Similarly, in the 1) case, "the webserver" should be "the SIP gateway" - 
there's some more reason to colocate them here, as SIP-over-HTTPS or 
SIP-over-Websockets makes some sense (and is already implemented by 
some), and is a little easier to deal with on a same-origin basis - but 
there's no necessary link between the Web server that serves the page 
and the SIP server that mediates the signalling.

That said, I also think it's more likely that designs based on 1) would 
be preferable.