On Friday, August 8, 2014 9:38:08 AM UTC-4, al...@instantbird.org wrote:
> Actually I wonder if pairs like BEGIN ACCEPT ... END ACCEPT
> might not be safer and easier to implement.
I think I like this better, it's clearer.
> > What would be gained by a WebRTC Capabilities request? Are
> > you thinking so that we can enable/disable buttons in
> > conversations?
> Yes, exactly. But I think it should be enough to just enable
> the button if CLIENTINFO WEBRTC is received.
That seems reasonable for now. We can add some querying later, if need be. (WEBRTC CAPABILITIES probably sounds reasonable.)
Florian also asked me about throttling since this could be a good amount of lines of network traffic all at once. I had thought that ISUPPORT had a flag about message flooding we should implement...but I can't seem to find it. So, yes. This is a concern, I think we just should throttle our message rate (we should probably be doing this anyway). Bug 954167  was about implementing that. Does anyone have other suggestions of how to handle this?
Florian also brought up this concept of "trickle ICE": when instead of giving us one SDP with all the network candidates, createOffer (or createAnswer) returns immediately what it already knows and gives us later additional candidates once it has them. We should at least ensure the protocol can handle this.