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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 15 February 2013 02:59 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 C3C2021F88BC for <rtcweb@ietfa.amsl.com>; Thu, 14 Feb 2013 18:59:16 -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 kYkcqUQcpblW for <rtcweb@ietfa.amsl.com>; Thu, 14 Feb 2013 18:59:16 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0620021F8573 for <rtcweb@ietf.org>; Thu, 14 Feb 2013 18:59:15 -0800 (PST)
Received: from [192.168.1.101] (p508FB4E4.dip.t-dialin.net [80.143.180.228]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 388561C0C0BF3; Fri, 15 Feb 2013 03:59:13 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@mail.gmail.com>
Date: Fri, 15 Feb 2013 03:59:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E2722E7-F82A-48D4-80FB-C76929A2E324@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>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1283)
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 02:59:16 -0000

On Feb 15, 2013, at 2:13 AM, Martin Thomson wrote:

> On 14 February 2013 14:58, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>> You could use the PPID of SCTP and would not need the in-band messages...
> 
> Interesting thought.  I'm not sure that I know how to do that.  I
> presume that this would require signaling to establish that PPID X is
> binary and PPID Y is text, amirite?
You register at IANA PPID X for binary and PPID Y (Y != X) for text.
No signaling required. 
> 
>> 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
I expect each data channel consisting of a pair of streams. Each stream
is contained in at most one data channel.

I consider each side managing only its outgoing streams. Therefore if
each side opens a data channel at about the same time, you end up
with two data channels. Assume that there are no data channels before that
and that you don't reserve any stream, chances are that each data channel
consists of out going stream with stream id 0 and incoming stream with
stream id 1.

Best regards
Michael
> 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?
>