One of the major issues in webinars or online classes are users with poor Internet connection complaining about the bad audio or video quality they are experiencing. They send us their Internet speed test reports and ping results to claim that they have a good connection and we can’t argue with them and explain how all the stuff works. So I’m trying to provide a way to prove them, in a simple and easy to understand manner, that this is all about their connectivity not the service.
The “Quality Adaptation Schemes” is one the tools that aims to help to detect, notify and adopt the video quality. Despite it works only for video and not audio, the main problem is that some times it is the publisher that has a poor connection not the subscribers. In this situation the adaptation mechanism does not help and still reports the issue to all subscribers!
I’ve also tried
stream.pc.peerConnection.getStats(), described here, to detect user connectivity issues by fetching and analyzing some useful data such as packets lost, nack count, jitter, etc. Unfortunately both tools and even Chrome WebRTC Internals have the same issue, that is a packet loss or delay in one side (publisher or subscriber) is reported by the other side!!
IMO in a p2p connection this makes sense because we can’t make sure whether the packet is lost in the publisher network or in the subscriber’s, but how about SFU?? The server should know what is going on. Am I wrong or this is a bug?
Any help would be appreciated.