We had a particularly disappointing and embarrassing result to a video call we set up the other day. After doing a series of tests for client using KMS with no ill effects, we had a real call in which the video started freezing and did so throughout. Freezing got so bad we had to terminate the call. A link to the recorded video of the call can be seen here
https://ms.talk-deck.com/tmp/kms_recorder_1590595062_48.webm
Moderator (woman) was in an office using her company office network in Montreal, hardwired, with 90GB up/.down speed. Presenter (man) was on home network on wireless laptop in Vancouver. Day before they did practice calls and everything seemed to be fine. On the real event - disaster.
Next day did another test session between same woman in office network, and a presenter in Toronto on wireless laptop. Disaster again.
https://ms.talk-deck.com/tmp/kms_recorder_1590675763_6.webm
To test again, I did call, this time between myself (hardwired home network in Montreal) and man in blue shirt from previous call. Call is perfect, no freezing.
(I tried to put a third link here but it wouldn’t let me. I will put third link in a subsequent reply)
Can there be something in a corporate office network (which has a sophisticated distributed network infrastructure) versus a simple home network (which has only a connection to a router) that is causing this video freezing?
Sorry to hear your problems. WebRTC real time streaming is hard, and we do our best to improve the platform to overcome any possible client side situation.
Answering your question: “Can there be something in a corporate office network (which has a sophisticated distributed network infrastructure) versus a simple home network (which has only a connection to a router) that is causing this video freezing?”
Yes. If you have properly deployed OpenVidu and you have checked that its behavior is fine, then if some client experiences strange behaviors, it is very likely that the networking in that specific client side is messing with the streaming. This is normal, and the fact that there is an infinite amount of client-side configurations regarding their networking and devices, is what makes WebRTC hard. I myself often experience problems with OpenVidu, Skype and other similar services at home from my room, where my WiFi signal is very poor.
That being said, we must always try to provide the best possible streaming experience even in these cases (prioritzing audio over video, dynamically chaning bitrates…). OpenVidu already do stuff under the hood to manage these kind of situations. But there can be some specifc cases where media may not flow as expected. If your experience is that everything works as expected in your own tests but when someone from certain corporate network tries to use the service is having problems, then it is possible that their particular setup conflicts in some way with the service. Debugging these issues is also hard, but if you provide to us the openvidu-server logs generated when the issues are happening, we might be able to find why is it behaving like that.
Regards.
Thanks Pablo, since my initial post we’ve gone through more problem analysis and think we’ve narrowed it down to the possibility the problem is being caused by this corporate client using the SonicWall Internet Security Platform.
We found this post from last year which seemed to suggest ‘SonicWall possibly blocking WebRTC’ traffichttps://www.reddit.com/r/sonicwall/comments/94efxq/sonicwall_possibly_blocking_webrtc_traffic/
Has anybody experienced a similar problem with SonicWall, and if so, how did you deal with it?
It seems SonicWall can cause problems with WebRtc call. People reports on Internet that audio/video is not working at all. But you report frozen audio/video after a while, right?
Maybe the firewall just cut the connection after a while. Maybe it can be configured somewhere in the the firewall.