IETF Logo Mail Archive

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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Fri, 15 February 2013 21:56 UTC

Return-Path: <matthew.kaufman@skype.net>
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 05E8421F85BC for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 13:56:49 -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 TulMZfzCBsRA for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 13:56:48 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24321F85B8 for <rtcweb@ietf.org>; Fri, 15 Feb 2013 13:56:48 -0800 (PST)
Received: from BL2FFO11FD026.protection.gbl (10.173.161.202) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 15 Feb 2013 21:56:40 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 15 Feb 2013 21:56:39 +0000
Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.200]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Fri, 15 Feb 2013 21:56:13 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] Data Channel Negotiation and reopening of decisions
Thread-Index: AQHOCdZYMz/8j5wte0qYTJYB9U+v5ph4WFUAgADD1ACAANcTgIAABrmAgAAlkICAAB2rAIAA7tYAgAA94wCAAAWzAIAAC0Eb
Date: Fri, 15 Feb 2013 21:56:12 +0000
Message-ID: <DA07C056-3E80-4E30-B078-5547A174549D@skype.net>
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>
In-Reply-To: <CABkgnnWdjV7F9jkbap91q-pLygzWJsTvAOh-m=-9q4VrU9DGUg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(189002)(199002)(24454001)(56776001)(31966008)(74502001)(54316002)(47446002)(44976002)(56816002)(74662001)(47776003)(20776003)(63696002)(16406001)(76482001)(79102001)(50466001)(4396001)(77982001)(59766001)(54356001)(80022001)(53806001)(46406002)(46102001)(5343655001)(5343635001)(51856001)(33656001)(65816001)(47976001)(47736001)(50986001)(49866001)(23726001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB038; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07584EDBCD
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:56:49 -0000

None if this would be a problem if we weren't making the mistake of using SCTP, which itself made the mistake of doing full-duplex channels instead of unidirectional channels with optional one-to-one or even many-to-one associations (as RTMFP has, as an example)

Matthew Kaufman

(Sent from my iPhone)

On Feb 15, 2013, at 1:16 PM, "Martin Thomson" <martin.thomson@gmail.com> 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.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email