Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

Randell Jesup <randell-ietf@jesup.org> Tue, 12 March 2013 08:00 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 EEB9B21F86AF for <rtcweb@ietfa.amsl.com>; Tue, 12 Mar 2013 01:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 2mTWj27b5nP7 for <rtcweb@ietfa.amsl.com>; Tue, 12 Mar 2013 01:00:27 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CBD2421F8917 for <rtcweb@ietf.org>; Tue, 12 Mar 2013 01:00:24 -0700 (PDT)
Received: from [216.53.157.5] (port=27295 helo=[10.96.3.64]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1UFK8F-0000TN-9Y for rtcweb@ietf.org; Tue, 12 Mar 2013 03:00:23 -0500
Message-ID: <513EE098.3040806@jesup.org>
Date: Tue, 12 Mar 2013 04:00:24 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.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
Subject: Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.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, 12 Mar 2013 08:00:28 -0000

On 3/11/2013 5:20 PM, MARCON, JEROME (JEROME) wrote:
>
> > Assuming that some day a spec defines the transport of T.140 (or 
> whatever similar protocol) over RTCWeb data channels
> > - with a registered subprotocol
> > - with multiple reliability options supported
> > - requiring some new data channel properties
> > - of which some are assymetric between the endpoints (like the 
> "characters per second" defined in [RFC4103].
> >
> > Then (in the current version of your proposal) it seems to me that
> > * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> > - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
> Why is it not extensible? We have a message type and you could simply
> define another message...
>
> [JM1]. Mmh, then the spec defining T.140 (or whatever) over data 
> channels (and willing to add a new property like "cps") would have to 
> define a new message type - and more less its own DATA_CHANNEL_OPEN 
> structure? That's a costly extensibility.

It you need to do a more complex negotiation, you have several choices.  
One would be:

Open a reliable data channel for negotiation (0 RTT) (flagged by label & 
protocol).  Over that channel, immediately send a message that sets up 
an offer for T.140 (take your pick on format. A JS app would likely use 
JSON), with a channel which was preset with the appropriate options ("I 
expect to receive data on this channel with these options").  The 
answerer can send back the response (on the negotiation channel), and 
also say "I expect data on this channel with these options").  At this 
point, the T.140 channel is open, and as soon as the response is 
received by the offerer, both sides know it.

If this sounds very much like "fast-path re-negotiation" for JSEP, it 
is.  Once you have DataChannels, you can leverage them to do a lot of 
things.  This sort of sequence is enabled by the ability added to allow 
external negotiation.  This is as fast as any other mechanism (and 
faster than any that goes via a signaling server) - 3 messages, 1 RTT 
total.  (Open, Offer -> Answer)

You can do this in SDP if you wish (and are willing to parse SDP, or 
whatever limited SDP  you need).  As mentioned, I normally would suggest 
JSON or something like that for JS Apps.)

You can also do external negotiation over whatever channel and method 
you like.

-- 
Randell Jesup
randell-ietf@jesup.org