Subject: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Tue, 19 Feb 2013 00:07:28 +0000

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.

This is a first draft, thanks for your suggestions of improvements.

Jerome 

________________________________________
De : [email-masked] [[email-masked]]
Date d'envoi : mardi 19 février 2013 00:30
À : MARCON, JEROME (JEROME)
Objet : New Version Notification for    draft-marcon-rtcweb-data-channel-management-00.txt

A new version of I-D, draft-marcon-rtcweb-data-channel-management-00.txt
has been successfully submitted by Jerome Marcon and posted to the
IETF repository.

Filename:        draft-marcon-rtcweb-data-channel-management
Revision:        00
Title:           RTCWeb data channel management
Creation date:   2013-02-19
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-marcon-rtcweb-data-channel-management-00.txt
Status:          http://datatracker.ietf.org/doc/draft-marcon-rtcweb-data-channel-management
Htmlized:        http://tools.ietf.org/html/draft-marcon-rtcweb-data-channel-management-00

Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP.  How to transport application messages on these
   data channels seems straightforward (i.e. they can be carried as SCTP
   user messages), however it is yet to be decided how to establish and
   manage these data channels.  This document specifies a method for
   this, which relies first on a lightweight and scalable out-of-band
   negotiation of data channel configurations (within the SDP offer/
   answer exchange) and second on the signaling of the configuration in
   use in the SCTP user message itself.  Once these configurations are
   negotiated, further creations of data channels can occur purely in-
   band by simply sending user messages, which avoids to define a new
   in-band data channel protocol.

The IETF Secretariat

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Feb 2013 01:49:21 -0500

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

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
[email-masked]