3 ms·
Another nitpick: WebRTC connections are extremely fragile and a pain to herd. We’ve had to build both data and audio keepalives into Squawk[1] to ensure that we
by zumachase 6y ago
Another nitpick: WebRTC connections are extremely fragile and a pain to herd. We’ve had to build both data and audio keepalives into Squawk[1] to ensure that we can hold connections for long durations (running in the background 24/7). And if the connection encounters a problem, often the only recourse is to renegotiate or recycle.
[1] https://www.squawk.to https://www.squawk.to
EDIT: For anyone curious, we swap out the track from the RTCRtpSender so we’re not transmitting any data when we’re muted (muting the track locally means you’re still sending frames of silence every 20ms which eats up cpu and bandwidth). And every 15 seconds we send a 60ms blast of silence, and verify on the receiver every minute.
- memexy 6y agoThis seems like an issue with residential network infrastructure more than webRTC. Do other peer-to-peer technologies work better than webRTC?
- zumachase 6y agoI can’t speak to other P2P tech, but I presume so. As far as I know, no other P2P tech runs at a big level, sandboxed abstraction of what’s really going on. And therein lies the rub of WebRTC. It was supposed to be a portable high level standard, but it isn’t portable so we’re just left with the costs of being high level.
- pthatcherg 6y agoWhy not just use ICE connectivity checks? That's what they are for. And I have proposed additions to the WebRTC API to allow control of when ICE checks are sent and how long a particular ICE candidate pair should stay alive (you could set it to "forever"): https://github.com/w3c/webrtc-ice/pull/22 https://github.com/w3c/webrtc-ice/pull/22