IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Fri, 15 February 2013 01:13 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 516D821F892D for <rtcweb@ietfa.amsl.com>; Thu, 14 Feb 2013 17:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.657
X-Spam-Level:
X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 B02pyi7D8tSd for <rtcweb@ietfa.amsl.com>; Thu, 14 Feb 2013 17:13:02 -0800 (PST)
Received: from mail-we0-x22b.google.com (we-in-x022b.1e100.net [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 668F421F88BC for <rtcweb@ietf.org>; Thu, 14 Feb 2013 17:13:02 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u54so2531600wey.16 for <rtcweb@ietf.org>; Thu, 14 Feb 2013 17:13:01 -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=YDidxIxuNX3CiKxC2r7JYYuSCtnHDlMfJMs9Z9Kd5H0=; b=B0+L2Yy923nWD47nLmA03a4RNf+H26WU2p01/bLmu8425xtXUMNXVYWoN57xj/BnQS d4PUsWb8hNqfQtRK0wLpbAJpHtEpS4s1ENseebaCDUmqZqdyFm8GcIXMeZeeS8N6XO6q nw1P6FzB3n7saeD4j4boutum2XUWXbRf/rjZoW8PDwqJ/j8WgvvHgWKIFll9nwPfLoez qxOJP3SvD83qh2FYMYkNCp8R1kryuym6NySDUDjNp2CJLo8SNs2LqSYVS3o7c8HVCo06 wHTLpWApI4oUcVC2C0YrAvJPH2Y29udgthlnzSJbwc5q/QEV9ro1HwTO/7jA+wESuERe 3ymg==
MIME-Version: 1.0
X-Received: by 10.180.77.9 with SMTP id o9mr2958076wiw.16.1360890781348; Thu, 14 Feb 2013 17:13:01 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Thu, 14 Feb 2013 17:13:01 -0800 (PST)
In-Reply-To: <89FAFB5C-9D03-4B76-A306-01F9E4EC4105@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>
Date: Thu, 14 Feb 2013 17:13:01 -0800
Message-ID: <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@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 01:13:03 -0000

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?

> 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?

v2.23.0 | Report a Bug | By Email