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.
- [rtcweb] Data Channel Negotiation Martin Thomson
- Re: [rtcweb] Data Channel Negotiation Randell Jesup
- Re: [rtcweb] Data Channel Negotiation Martin Thomson
- Re: [rtcweb] Data Channel Negotiation Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation Randell Jesup
- Re: [rtcweb] Data Channel Negotiation Martin Thomson
- Re: [rtcweb] Data Channel Negotiation Martin Thomson
- Re: [rtcweb] Data Channel Negotiation Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation Martin Thomson
- [rtcweb] Data Channel Negotiation and reopening o… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Stefan Håkansson LK
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Cullen Jennings
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Ted Hardie
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Thornburgh
- Re: [rtcweb] Data Channel Negotiation and reopeni… Ted Hardie
- Re: [rtcweb] Data Channel Negotiation and reopeni… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Data Channel Negotiation and reopeni… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Data Channel Negotiation and reopeni… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Michael Tuexen
- Re: [rtcweb] Data Channel Negotiation and reopeni… Tim Panton
- Re: [rtcweb] Data Channel Negotiation and reopeni… Harald Alvestrand
- Re: [rtcweb] Data Channel Negotiation and reopeni… Paul Kyzivat
- Re: [rtcweb] Data Channel Negotiation and reopeni… Martin Thomson
- Re: [rtcweb] Data Channel Negotiation and reopeni… Paul Kyzivat
- Re: [rtcweb] Data Channel Negotiation and reopeni… Paul Kyzivat
- Re: [rtcweb] Data Channel Negotiation and reopeni… Stefan Håkansson LK
- Re: [rtcweb] Data Channel Negotiation and reopeni… Randell Jesup
- Re: [rtcweb] Data Channel Negotiation and reopeni… Paul Kyzivat
- Re: [rtcweb] Data Channel Negotiation and reopeni… Harald Alvestrand