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

Harald Alvestrand <harald@alvestrand.no> Wed, 20 February 2013 19:40 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1525E21F86CB for <rtcweb@ietfa.amsl.com>; Wed, 20 Feb 2013 11:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.407
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P10K5lBk0F4 for <rtcweb@ietfa.amsl.com>; Wed, 20 Feb 2013 11:40:27 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C52BB21E8030 for <rtcweb@ietf.org>; Wed, 20 Feb 2013 11:40:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73D6039E15B for <rtcweb@ietf.org>; Wed, 20 Feb 2013 20:40:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tQo4tVFtTMM for <rtcweb@ietf.org>; Wed, 20 Feb 2013 20:40:22 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2DF4B39E0CE for <rtcweb@ietf.org>; Wed, 20 Feb 2013 20:40:22 +0100 (CET)
Message-ID: <512526A4.2020107@alvestrand.no>
Date: Wed, 20 Feb 2013 20:40:20 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnWUpMSBLioSD2+p82vGszX9R0Q4WFfME5j-DuK+B7KVJw@mail.gmail.com> <CABkgnnW792o76t9dKhidOMJpa21VcbPQZFU1HYnY_yjTPCWhYw@mail.gmail.com> <51166A3C.4000604@jesup.org> <CABkgnnV2m=m+qtM1YR4CPse=gyekvWThon_Nxbf8YMVaNuvq6Q@mail.gmail.com> <511B6C9A.4090904@jesup.org> <CABkgnnUiCKuv_=mgLFf4sRnOb1bY190N7E_+V8gfTbKEUTBnDw@mail.gmail.com> <511CB20C.7020003@jesup.org> <CABkgnnU0idt+ntpKjTCMUCVFO9=_fSjGRPikD6Nk_Uem3L7E8g@mail.gmail.com> <89FAFB5C-9D03-4B76-A306-01F9E4EC4105@lurchi.franken.de> <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@mail.gmail.com> <8E2722E7-F82A-48D4-80FB-C76929A2E324@lurchi.franken.de> <CABkgnnWzX2tpbadnB3DjhmB7cm6poCDvmxdAW2Z_stMbovJ3gw@mail.gmail.com> <A0FDFC7C-2C85-431C-A03E-0E486F9378D1@lurchi.franken.de> <CABkgnnWdjV7F9jkbap91q-pLygzWJsTvAOh-m=-9q4VrU9DGUg@mail.gmail.com> <AC720CBD-AD12-4696-AA4F-2D5BADAF6BD5@phonefromhere.com> <5122B865.8080700@alum.mit.edu> <51233CC6.1060706@ericsson.com> <512524CC.6040404@alum.mit.edu>
In-Reply-To: <512524CC.6040404@alum.mit.edu>
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-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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
>>>>> <Michael.Tuexen@lurchi.franken.de> 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.