Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

Randell Jesup <randell-ietf@jesup.org> Mon, 29 April 2013 21:57 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 EB47021F9BBB for <rtcweb@ietfa.amsl.com>; Mon, 29 Apr 2013 14:57:06 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHwpaUwAPRJ1 for <rtcweb@ietfa.amsl.com>; Mon, 29 Apr 2013 14:57:01 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E40EB21F9BA8 for <rtcweb@ietf.org>; Mon, 29 Apr 2013 14:57:00 -0700 (PDT)
Received: from 173-164-135-225-sfba.hfc.comcastbusiness.net ([173.164.135.225]:57628 helo=[10.1.10.57]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1UWw4B-0004n3-Vx for rtcweb@ietf.org; Mon, 29 Apr 2013 16:57:00 -0500
Message-ID: <517EECAB.3010206@jesup.org>
Date: Mon, 29 Apr 2013 14:56:59 -0700
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <066.3120a55540cacaa74ee5fda0b5273a48@trac.tools.ietf.org> <5174C8D2.40504@matthew.at> <5177F7EE.1010909@matthew.at> <CAJrXDUGa1=Nqq9WPL57=OkUU9mG7yHz0uzG1KncS8yVzbSAM0A@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A484162816C1@tk5ex14mbxc272.redmond.corp.microsoft.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11349F9B5@xmb-aln-x02.cisco.com> <5179A362.2000309@jesup.org> <517A86CB.5020305@matthew.at> <517ABB06.5070807@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3BB9C130@US70UWXCHMBA05.zam.alcatel-lucent.com> <BLU405-EAS394043F8B674970FE13010693B20@phx.gbl>
In-Reply-To: <BLU405-EAS394043F8B674970FE13010693B20@phx.gbl>
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
Subject: Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN
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: Mon, 29 Apr 2013 21:57:07 -0000

On 4/29/2013 9:40 AM, Bernard Aboba wrote:
> I would also note that the maximum number of streams can be indicated in the association negotiation.  So if there is concern about unexpected data channels and associated data, that mechanism can be used. If the application knows how many streams it will need, might it not be wise to indicate this in association setup?

The number of streams in the SDP is the initial number of streams (with 
a suggested default of 16).  That's entirely an optimization to avoid 
the application needing to immediately need to renegotiate a larger 
number, or to have a large number of never-used channels if the default 
was set way too high.

If streams are needed past the number currently allocated, an increase 
will be requested and the createDataChannel queued.  (Note: this applies 
to pre-negotiated channels using streams past the currently allocated 
number as well).

-- 
Randell Jesup
randell-ietf@jesup.org