IETF Logo Mail Archive

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

Tim Panton <tim@phonefromhere.com> Mon, 18 February 2013 11:45 UTC

Return-Path: <tim@phonefromhere.com>
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 3153F21F891D for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 03:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XXG9OTDTHqyE for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 03:45:54 -0800 (PST)
Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3421F8919 for <rtcweb@ietf.org>; Mon, 18 Feb 2013 03:45:53 -0800 (PST)
Received: (qmail 11755 invoked from network); 18 Feb 2013 11:45:48 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 18 Feb 2013 11:45:48 -0000
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3679B18A0ACE; Mon, 18 Feb 2013 11:45:48 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CABkgnnWdjV7F9jkbap91q-pLygzWJsTvAOh-m=-9q4VrU9DGUg@mail.gmail.com>
Date: Mon, 18 Feb 2013 11:45:46 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC720CBD-AD12-4696-AA4F-2D5BADAF6BD5@phonefromhere.com>
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>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup <randell-ietf@jesup.org>
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: Mon, 18 Feb 2013 11:45:55 -0000

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.

We run the risk of over thinking this.

T.

v2.23.0 | Report a Bug | By Email