Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt
Randell Jesup <randell-ietf@jesup.org> Tue, 19 February 2013 06:51 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 9E8D321F8D03 for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 22:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 53-npui-9o1T for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 22:51:39 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E446021F8D02 for <rtcweb@ietf.org>; Mon, 18 Feb 2013 22:51:38 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3710 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 1U7h3C-000Gms-9x for rtcweb@ietf.org; Tue, 19 Feb 2013 00:51:38 -0600
Message-ID: <51232071.3070207@jesup.org>
Date: Tue, 19 Feb 2013 01:49:21 -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: <20130218233047.19414.47123.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.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] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt
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: Tue, 19 Feb 2013 06:51:39 -0000
On 2/18/2013 7:07 PM, MARCON, JEROME (JEROME) wrote: > Hi, > > I have submitted a draft proposing a new way of setting up data channels, based on the concept of data channel configurations. It uses a lightweight SDP signaling coupled with a lightweight in-band signaling (not an in-band protocol). I think it can handle efficiently the most demanding setup scenarios. The proposal is besides designed with the intent to not impact on current browser API. Thanks. Still reading, but an initial comment: "Whenever the application creates a new data channel, the browser internally checks if the passed set of parameters strictly matches an existing configuration, and if not generates a new configuration identifier for this set. In the latter case only does the browser trigger the application for an SDP renegotiation." Wouldn't this occur on almost every channel because of label values? Or are you assuming applications won't actually use labels? "For each data channel configuration in the offer that is accepted by the answerer, the answerer echoes in the answer the configurations supported and accepted. Once the offerer receives the answer and (in case of an initial offer) the SCTP initialization is complete, each data channel locally created using one of the accepted configurations is signaled to the application as open for transmission." There's a bunch of API to surface here in order to support O/A ("for each ... that is accepted by the answerer..."). "By convention, the inbound and outbound streams of a data channel have the same SCTP stream number. This stream number is selected by the first endpoint sending a user message on this channel. Till this happens, an open data channel has no assigned stream number." How do you handle glare? (i.e. both sides start to send on stream 5 at the same time) "Data channel messages are sent as SCTP user messages, preceded in the DATA chunk User Data field by two bytes specifying data channel configuration identifier as well as the message data framing type (textual or binary)." Aha. So you've moved this into a true inband protocol with data framing. The current draft sends data messages with no added framing required. -- Randell Jesup randell-ietf@jesup.org
- [rtcweb] TR : New Version Notification for draft-… MARCON, JEROME (JEROME)
- Re: [rtcweb] TR : New Version Notification for dr… Randell Jesup
- Re: [rtcweb] TR : New Version Notification for dr… MARCON, JEROME (JEROME)
- Re: [rtcweb] TR : New Version Notification for dr… Salvatore Loreto
- Re: [rtcweb] TR : New Version Notification for dr… Randell Jesup
- Re: [rtcweb] TR : New Version Notification for dr… MARCON, JEROME (JEROME)