Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Randell Jesup <[e-mail]>]

On 9/17/2011 1:27 PM, Hadriel Kaplan wrote:
> On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote:
>
>> They will be able to use the rtcweb data channel, which is a concern.
> Yes, that's actually the most interesting piece of this whole thing, in my opinion.  Browsers don't typically offer raw sockets to javascript as far as I know.  And not only does it raise a lovely set of security concerns, but also network collapse issues since UDP has no congestion backoff and I believe the data channel we're talking about is UDP(?).

Actually DTLS channels; they're effectively UDP, but encrypted.  However,
per a few messages you'll have seen from me, discussion at the last IETF
and the call a week and a bit ago, we will plan to extend the congestion
control domain to include controlling the data channels.  Ironically
reliable data channels would be easier to handle than unreliable (you
could just use TCP-over-UDP); but we plan to do better than that.


> And since the data channel is actually peer-to-peer rather than client-to-server, the issues with not standardizing its protocol become harder. I.e., leaving it a raw socket will only work if it goes between the same javascripts, inside the same domain - if that's ok, then the only issue is this would be put into SDP, and SDP isn't constrained by a javascript domain.  Hmm... gosh, if only rtcweb didn't use SDP as its browser API...
> :)

Well, depending on how the data channels are set up, they may not be required
to include in the SDP at all; they could be instantiated on-demand in the
of an open PeerConnection.

Data channels at this point are assumed to be application-specific and not
subject to being exchanged during federation; we should think a little about this.


-- 
Randell Jesup
[e-mail]