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

[Hadriel Kaplan <[e-mail]>]

On Sep 16, 2011, at 4:43 PM, Ted Hardie wrote:

> We also have to make sure that the resulting application does not flood or fry the network. That means it will have to have real congestion control mechanisms.   Trusting the javascript application for that has some real issues which we've already discussed.   Splitting signaling and congestion control isn't a lot better.  If congestion control at the network level is managed by the browser but signalling is in the javascript, then information about that state has to pass into the JS application, so it can manage the signalling.  That makes the APIs more complex and runs the risk that a naive javascript application will not adjust to the congestion control requirements at all.

Yes you're right we have to make sure things don't collapse, but I'm confused why congestion control would be handled in the JS, or in signaling.  Wouldn't it be done in the RTP/RTCP layer, such as draft-alvestrand-rtcweb-congestion-00 or whatever, if the RTP peer supported it?  Who said it would be in signaling? (I must have missed something, or misunderstand you)

-hadriel