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

Paul Kyzivat <> Wed, 20 February 2013 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8417E21E8030 for <>; Wed, 20 Feb 2013 11:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.36
X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=0.077, 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 JOJqgFXptOy9 for <>; Wed, 20 Feb 2013 11:32:32 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:24]) by (Postfix) with ESMTP id C2C8A1F0D0B for <>; Wed, 20 Feb 2013 11:32:30 -0800 (PST)
Received: from ([]) by with comcast id 2d1f1l0041GhbT851jYVLE; Wed, 20 Feb 2013 19:32:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 2jYV1l00j3ZTu2S3TjYVz1; Wed, 20 Feb 2013 19:32:29 +0000
Message-ID: <>
Date: Wed, 20 Feb 2013 14:32:28 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1361388749; bh=fv0/5wDoRNzT39yhd9DKmpdIQbCo6310LQFVq105L20=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lO26dJSxJ5fWz0yX20D7hyYIdWPhfvoPlSLe641ALyqJ3ybDpeWNwuyBS/E6o67ni /ECNGJDKZJv/fpgh1StsLRofoxcjDPD0eDh9n7C7dM5AlT8+rK2YEWf2AU6IpxtqQ/ YYHu44LPefrPAh2WZcXcSvsSLsbf3dEVVQt/Y/HEQ50L3BnZHx8zCOfzQzlxfszFfm RHa6Dy1dij6pllamE79MRqBTkI0xE8NNrYftztF0tl1b0SWs4O3oVZeH4Dl6d8aele jr/Sm0VBoVkBhVScbI8/doZodCSY8aezRvZ+/gcM1w7yz5xeb24k4ZUvd8pDo2kqzs xQ7j7QugZjv1Q==
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:32:32 -0000

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 

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.