Re: [Bug 15206] Add API for sending and receiving p2p application data

On Thu, Jan 26, 2012 at 7:32 PM, Randell Jesup <randell-ietf@jesup.org>wrote:

> On 1/26/2012 3:15 PM, bugzilla@jessica.w3.org wrote:
>
>> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=15206<https://www.w3.org/Bugs/Public/show_bug.cgi?id=15206>
>>
>> --- Comment #9 from Justin Uberti<juberti@google.com>  2012-01-26 23:15:35
>> UTC ---
>> New in this version:
>>
>> Changes for Jan 2012 W3C meeting; tied DataStreams to a PeerConnection;
>> changed
>> DataStream base class; added MTU for unreliable streams; better WebSocket
>> alignment (added other send() variants, removed onreadytosend); added
>> reliable
>> and multiparty examples
>>
>
> Thanks Justin.
>
> I'll note that creating a datastream here requires a full renegotiation of
> the entire peerconnection (though one assumes the other items don't change
> state and thus would end up being no-ops after lots of processing occurs.


Not true if JSEP is used; with JSEP you can handle this however you see
fit, including having a set of pre-allocated channels that you use
whenever, or having your own application protocol (like what you mention
above) that allocates channels.

>
> There are alternatives that would not require renegotations of the
> peerconnection, as mentioned in a previous message thread titled "Data
> channel setup and signalling", starting 11/15/2011, or would only *require*
> negotiating one channel and use an application-specific protocol over that
> one to open additional ones.
>
> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg02861.html<http://www.ietf.org/mail-archive/web/rtcweb/current/msg02861.html>
>
> I'll repeat one bit from that which is relevant:
>
>   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.
>>
>
>
> Unless there's some higher-level structure imposed on the data somehow,
> data channels are inherently application-specific, so generic stream
> specifications and "negotiation" of them actually buys you very little
> (except *maybe* the first one).  This is different from audio and video
> streams and their encodings.


I thought about this a lot, but I think we probably want to impose
higher-level structure, for two reasons:
1) Multiuser. Hasn't been talked about too much in the context of data
channels, but without getting into too many details I think this is a
critical use case. In multiuser, you need to be informed of what channels
are available, changes as new channels become available, what their
reliable/unreliable status is, what user they correspond to, etc. I admit
that much of this could be done completely by the application, despite
being inconsistent with the handling of audio and video, but there is an
important exception:
2) 3rd party backend services. WebRTC is already spawning a number of
startups creating AWS-style signaling, gatewaying, and conferencing
services. For conferencing, the service will need to know the details of
how multiple streams are configured within a WebRTC session, as well as the
wire protocol, so that it can route the data properly without needing
special cases for each application (just like audio and video). This
implies we need to specify a way to negotiate the stream configuration.

I'm certainly not dead-set on this approach, but as we've started building
this stuff out, I'm finding that in many respects data has the same needs
as audio and video.

>
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
>
>