Re: [rtcweb] Data Channel Negotiation and reopening of decisions
Randell Jesup <randell-ietf@jesup.org> Sat, 16 February 2013 06:59 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 EB4BD21F8570 for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 22:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 bmum0cePNxPQ for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 22:59:09 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 608C121F855C for <rtcweb@ietf.org>; Fri, 15 Feb 2013 22:59:09 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2223 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 1U6bjo-000C5J-Jc for rtcweb@ietf.org; Sat, 16 Feb 2013 00:59:08 -0600
Message-ID: <511F2DB9.3040905@jesup.org>
Date: Sat, 16 Feb 2013 01:56:57 -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>
In-Reply-To: <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sat, 16 Feb 2013 06:59:10 -0000
On 2/14/2013 8:13 PM, Martin Thomson wrote: >> However, assuming datachannel are bidirectional, I really think we need some >> sort of signaling to set them up to avoid collisions. > Collision of what? The problem that the 1.5 RTT solves is not a > collision problem. It's a problem of a mismatch of configuration and > expectations on the two ends of the channel. If you remove the > expectations (negotiate if you care), and don't worry about matching > configuration (make configuration mutable, and again: negotiate if you > happen to care), what then? The 1.5 RTT solution was due to the W3 and IETF at Stockholm saying they wanted OnOpen events to only fire when we knew the other side had received them, IIRC, like WebSockets. My 0-RTT solution I've (re-)proposed doesn't loosen any of the consistency guarantees; it merely fires onOpen as soon as the channel is created*. You can send immediately. This also means there's no need to signal channels in the SDP. The only minor impact is that until the openResponse is received (1 RTT), packets are sent with the in-order flag. There are some minor details that would need to change from the current protocol definition, but nothing of significance. * createDataChannel before createOffer will not fire onOpen until the SCTP association comes up and onConnection has fired. I think the "just send on the next channel and ignore glare and accidental channel merges" is just handing a loaded gun to the application writer, where it normally works fine but occasionally in hard-to-test ways it malfunctions. If you want bidirectional channels, you either negotiate (SDP) or you use something like this (which allows mis-matched streams to build a channel). -- Randell Jesup randell-ietf@jesup.org
- [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