IETF Logo Mail Archive

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

Randell Jesup <randell-ietf@jesup.org> Tue, 19 February 2013 15:00 UTC

Return-Path: <randell-ietf@jesup.org>
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 B667921F8C61 for <rtcweb@ietfa.amsl.com>; Tue, 19 Feb 2013 07:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
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 l7hC11oUFhsq for <rtcweb@ietfa.amsl.com>; Tue, 19 Feb 2013 07:00:51 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3621F880F for <rtcweb@ietf.org>; Tue, 19 Feb 2013 07:00:47 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1575 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1U7ogZ-0002A4-7P for rtcweb@ietf.org; Tue, 19 Feb 2013 09:00:47 -0600
Message-ID: <51239314.1010809@jesup.org>
Date: Tue, 19 Feb 2013 09:58:28 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnWUpMSBLioSD2+p82vGszX9R0Q4WFfME5j-DuK+B7KVJw@mail.gmail.com> <5113CD16.6090806@jesup.org> <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>
In-Reply-To: <51233CC6.1060706@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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: Tue, 19 Feb 2013 15:00:53 -0000

On 2/19/2013 3:50 AM, Stefan Håkansson LK wrote:
> On 2013-02-19 00:25, Paul Kyzivat wrote:
>>
>> 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).

If you have any sort of central mixer usecase (Hangouts?) it makes lots 
of sense for the server to implement DataChannels.  Also for any case 
where the server is proxying them, since (eventually) we'll have them 
set not to conflict congestion-wise (or be controllable in priority).

-- 
Randell Jesup
randell-ietf@jesup.org

v2.23.0 | Report a Bug | By Email