My connection is via WiFi, and the WiFi stays connected and everything, but no connection to neither zencastr.com, fast.com, google.com works.
The tool uses WebRTC for the call, hence I assume it might have something to do with that, but my assumption so far was always that a website I open in my browser does not have any effect to the underlying network stack or so.
When I use a competitor tool, riverside.fm or google meet (both using WebRTC as well) I don't have any of this problems.
My question: Is it possible that a bug in their WebRTC kills my internet? If yes, shouldn't that be prohibited by whatever security mechanism in my browser?
Well, days of troubleshooting later and we found a common network segment they all hit somewhere in Wisconsin, and the owner of that physical network found a bad piece of hardware on a telephone pole. I forget the details of what the hardware was or why it threw a fit with our site but not others... but the bigger point is that there are many layers in a network, so while software might be the problem... it also might not.
So my approach has always been that if it makes no sense for software to be causing an observed problem - investigate the other layers.
Try doing internet-related things outside the browser, in order to rule that out. Use curl or wget from a terminal, for example. Try a different browser while this is happening. Hell, try a different browser in general and see if the same issue gets triggered with the different browser.
It's also possible that some traffic pattern that happens to occur on zencaster is triggering a bug in your router's network stack. If that's the case, it would (probably) affect other devices on the network, too, like another computer or phone.
If I were you, I'd confirm if the issue continues if on wired ethernet, and investigate from there. I personally won't do conferencing on wireless anything, jitter and unnecessary latency are the death of interactivity; but a lot of people disagree with me, I guess.
[1] Ugh, PPPoE is garbage, but my other choices are either worse or involve tremendous expense.
Try running this tool before, during and after you have problems: https://devina.io/speed-test
Google and I imagine other specialized sites do play some trickery with how they craft their TCP packets potentially to avoid some things like this. So it is possible that it's less a bug in their web RTC and more an optimization with the other sites that don't have this same behavior.
It's really difficult to tell beyond some general speculation without some packet captures bandwidth graphs and packets per second measurements.
Try using the offending website on a browser/OS that _doesn't_ have WebRTC such as https://caniuse.com/?search=webrtc. Or try with WebRTC disabled.
Possible you're getting throttled by your router or ISP when certain connections are made.
And there's this https://browserleaks.com/webrtc
Always binary search: rule out the browser by doing it a different way. Rule out the machine by trying it on a different device, etc etc.
I'd first try on a different WiFi that has both a different router and ISP. That should narrow down where you have to search for the problem.