Re: [rtcweb] Data channel setup and signalling

[Saúl Ibarra Corretgé <[e-mail]>]

HI,

On Nov 15, 2011, at 7:42 AM, Randell Jesup wrote:

> The signalling discussion and how it touched on data channels got me thinking.
> 
> One open issue is how we define data channels, both in the "internal" case (no interop) and the federated case (which may have the same JS app or different ones at either end).
> 
> One solution is that all data channels are defined as m= lines.  They could be generic "m=data", or they could specify the data to be passed in the m= line.  For "public" message structures that might be used by different applications (an IM protocol, for example), one would specify that in some manner in the media description (perhaps via a MIME type).  This also implies that any addition or removal (or change to) a data channel requires a full replacement OFFER and ANSWER.  If we stick with the SDP requirement about never removing m= lines, then the OFFER size may become unbounded.
> 

Once a stream is removed apart from setting the port to 0 all attributes may be removed to save some space (sorry, can't find where I read that :-S). Yes, it could still grow infinitely, but I've doing this for quite some time now (adding and removing audio, MSRP chat and MSRP file transfer streams) and only cheap-hotel wifi networks choked on SDP size. ;-)

> The other option is to have (some) data channels be separate from media, in particular app-specific anonymous data channels.  There's no requirement for describing the channels if they're private to the app, at least to the first approximation.  An app could pre-define data channel 3 as a private message structure for game map updates, so long as it knows its talking to itself.
> 
> This has advantages in setup time, especially if the data channels are dynamic and invoked via another data channel, since there doesn't have to be a full offer-answer including the media channels.  You just need to make sure the two sides agree on the data to be exchanged and that they listen before receiving data.  It has a minor advantage in reducing the amount of information leakage to the server about the creation and types of streams (and potentially significant metadata about them).
> 
> 
> A use-case would be a background http proxy-server during chat.  If you have to re-OFFER for each data channel that comes and goes to transfer a resource, it will both swamp the server and be slow (due to the triangle signalling).  If instead the application can open a single control data channel, and invoke transfers over it, the application can efficiently transfer a high number of URIs.  Are there other ways to do this without re-OFFERing constantly?  yes.  But they generally involve building protocols on top of an array of long-lasting generic connections.
> 
> For example, the control data channel might pass messages (directly browser-to-browser) like
> {
>   id: 1,
>   command: "GET",
>   URI: "blah/foo/bar",
>   channel: 5,
> }
> with an answer:
> {
>   id: 1,
>   result: "ok",
>   size: 1234,
> }
> followed by transfer of the URI on data channel 5.  (Note: in this I'm assuming an API that lets the app open a specific data channel of the peer connection.)
> 
> Now, this is contrived, though plausible.  You could pre-open a bunch of idle data connections and then re-use them as needed.  The counter-argument is that one could write a connection-server library that abstracts a bunch of pre-opened data channels into an API for the app that works like I described above, though it may require more housekeeping and larger fixed resource usage.
> 
> 
> So.....
> 
> Is it worthwhile to consider interfaces/APIs whereby an application could directly open data channels with no re-OFFER and implement a control protocol similar to the one I described?  Are there other use-cases for high-volume data channel create/removal, or where data channel latency creation is critical? (my usecase is a little contrived since I'm falling asleep a the keyboard.)
> 

Your proposal seems fine to me. Some may want to negotiate the data channel, some may not. A use case that comes to mind for a high-volume data channel usage would be file transfer using MSRP for example (assuming it's a valid use case).


Regards,

--
Saúl Ibarra Corretgé
AG Projects