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 Room.getStreamStats()
and 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.