IETF Logo Mail Archive

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

Ted Hardie <ted.ietf@gmail.com> Fri, 15 February 2013 18:04 UTC

Return-Path: <ted.ietf@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 84D7E21F8808 for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 10:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.040, 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 CQdvW-OXiLmo for <rtcweb@ietfa.amsl.com>; Fri, 15 Feb 2013 10:04:11 -0800 (PST)
Received: from mail-ie0-x236.google.com (ie-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9AE21F85C0 for <rtcweb@ietf.org>; Fri, 15 Feb 2013 10:04:11 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id k14so5144795iea.13 for <rtcweb@ietf.org>; Fri, 15 Feb 2013 10:04:10 -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=66lTADhSpTn/GS9Stceqg8s3vFhn1WkJyZXM8OD03c8=; b=NErlx6trHvi9zsyzhqb+448PVaTzkWFRXcGsO8QFXJdUxgzqmbQkDnYmb9/r3szldU oOpqbBhn3JkkidFm6aE+VnVWPMglPZB0uKpqDVDL+gQFat5qJR8gqNs5gvTJ4SVPI2FW H8HfhKHpQyFmIs/w0tNEF1uV9y5E8sN2dGjKn3ffEjdD/N7lhv80xFk5bBPa00NedrFk 4BMvcNl48hXhqb5als/5irVyVNZDvAhHyNKue1WGt6vg+6aA49K5WBssubFog7TGitvB wlxZxWhUDqi6NN2WCPbOmE04tu+EpQCLqKyAqbMlQdg7EElBHINL8yUMqTwG4eQdAJs7 UMcA==
MIME-Version: 1.0
X-Received: by 10.50.194.134 with SMTP id hw6mr2557085igc.20.1360951450740; Fri, 15 Feb 2013 10:04:10 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Fri, 15 Feb 2013 10:04:10 -0800 (PST)
In-Reply-To: <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> <8E2722E7-F82A-48D4-80FB-C76929A2E324@lurchi.franken.de>
Date: Fri, 15 Feb 2013 10:04:10 -0800
Message-ID: <CA+9kkMDYKdxicZRrgUn5UaPa3PjOm3v4pXQjmX_PGLQ6tftPJg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"
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 18:04:11 -0000

On Thu, Feb 14, 2013 at 6:59 PM, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
>
> 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.
>

Sorry for being dense, but if you get an INIT where the Stream
Identifiers in the data
chunk are already in use, why wouldn't you error out?  Alternatively,
can existing
implementations keep that straight as a tuple of SCTP association,
stream identifier?
If the latter, then occasionally having two data channels instead of
one does not
seem to be that big a deal; am I missing something?

regards,

Ted

v2.23.0 | Report a Bug | By Email