IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Fri, 15 February 2013 21:15 UTC

Return-Path: <martin.thomson@gmail.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 4A28221F85C4 for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 13:15:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.644
X-Spam-Level:
X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 4lQjAGdw00pJ for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 13:15:57 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A581A21F85B0 for <rtcweb@ietf.org>; Fri, 15 Feb 2013 13:15:57 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id d7so3223435wer.8 for <rtcweb@ietf.org>; Fri, 15 Feb 2013 13:15:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6Y4/QOudDmhWEbAhpaGlP0f3NzEz1tnk2SbquH97Ass=; b=RESpZOD+sMG9VLyGyTDbZ0A5sN2Gcx7Lzngyu1Dc6ohv8hI7+qnsaVmABtAa357PuZ mzn1V+KWapdSaF+AlASTZwdFblDd3g2tVMB1CtPvD+E7Su27rFGuLhcGzfnIEYOQAs11 CgPEjIwaeCGtVpaXJqfHBOkRf/EWUQyJOFYp1c59nt1grb1DvI5XdjPBUuQgHzKr1Q7W bJGu4kkCo8a6Sc93Vwg2xC24h19ccm33RzcQhE5rgqpiG8lhFYZXNA6RZ5D9A7w8txgl geMNZ9NB+ZkcAOmiMzjnwCibQz8JtUrLqp+EJH09hIoR3Sug0MiWRZJrX5mE/olCUlP8 cBGw==
MIME-Version: 1.0
X-Received: by 10.180.108.229 with SMTP id hn5mr4744383wib.28.1360962956869; Fri, 15 Feb 2013 13:15:56 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Fri, 15 Feb 2013 13:15:56 -0800 (PST)
In-Reply-To: <A0FDFC7C-2C85-431C-A03E-0E486F9378D1@lurchi.franken.de>
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>
Date: Fri, 15 Feb 2013 13:15:56 -0800
Message-ID: <CABkgnnWdjV7F9jkbap91q-pLygzWJsTvAOh-m=-9q4VrU9DGUg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Content-Type: text/plain; charset="UTF-8"
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.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: Fri, 15 Feb 2013 21:15:58 -0000

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.

v2.23.0 | Report a Bug | By Email