Re: [rtcweb] Data channel setup and signalling

[Justin Uberti <[e-mail]>]

On Tue, Nov 15, 2011 at 4:25 AM, Harald Alvestrand <[e-mail]>wrote:

> On 11/15/2011 02:42 PM, 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.
>>
> Just to add to the confusion:
> If one instead keeps the (each?) SCTP connection as one m= line, one could
> instead model the data channels as corresponding to SSRCs, and reuse the
> codec declaration mechanisms from RTP m= lines to assign specific data
> syntaxes to each SSRC....
>
> this seems to me to be a model that adheres more closely to the RTP model,
> but that doesn't mean it's a good fit to SCTP, or a good fit to real
> applications' real requirements.
>
>
>
>> 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.
>>
> This example in fact VERY closely resembling FTP..... make the commands
> one-line instead of JSON blobs, and the responses into numeric codes, and
> the resemblance is just about uncanny....
>
>
>> 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.)
>>
>>  I kind of like the idea of being able to open data channels with no
> re-offer; we could pattern the API of new incoming data channels on the
> handling of SSRCs that weren't mentioned at negotiation time .... not that
> we've worked that out at the API level, last time we discussed it, I think
> it was suggested that any new SSRC was signalled as a new MediaStream...
>
>
I'd prefer to have one way of doing things that's consistent, i.e. using
re-OFFER for adding datastreams or SSRCs. This wouldn't have to be slow; if
you already had a datastream, as you indicate in your example, the re-OFFER
could occur over this path. Doing it this way would also allow metadata
regarding the SSRC or datastream to be communicated to the other side prior
to using the stream.

>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>