Re: [rtcweb] Data channel setup and signalling

[Stefan Håkansson LK <[e-mail]>]

On 11/15/2011 07: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.
>
> 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.

I like this. Is there really a need to signal individual data channels 
at all (except for setting up data - one m-line saying "data")?

When data is available the allocation of channels can be handled by the 
app itself with no associated signaling. Either the app knows that 
channel 3 is always used for this and channel 5 for that; or the app 
signals using one predefined channel the contents of the other channels.

For the federated case, there could be a document describing what to use 
the channels for (if needed).


>
> 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.)
>