Re: [rtcweb] Data channel setup and signalling

[Harald Alvestrand <[e-mail]>]

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