Broken bandwidth estimation in stable-5765-1 (websockets disabled)

Has anyone gotten good quality video meets with 3+ people on stable-5765(-1) ?
In all of my setups, the available downstream bandwidth is estimated terribly low (e.g. hundreds of kbps when real bandwidth is >=1Gbps on a LAN or virtio-net connection – upstream estimation looks reasonable as well). I get 320x180 then (which is what I set for min), which is terrible, when HD would work without any trouble and actually did on stable-5390-x.

So something looks completely broken with downstream BWE here.

(I tried to enable VP9, by the way, but disabling it again does not fix things. Nor does playing with Rtx, Tcc, Remb settings.)

Reading Flagship VP9 Support: Notes and Discussion - #147 by emrah
and the following posts …
I do have websockets disabled. Never got them to work!
The broken bandwidth estimate reported in the VP9 discussion seems not to be exclusive to VP9…
It seems to be always happening with -5765-[01].

I still can’t possibly get XMPP_WEBSOCKET to work.
Not disabling COLIBRI_WEBSOCKET however seems to be enough to make bandwidth estimation work again, yeah!

What is your setup? Are you behind a reverse proxy? If so please check this: Self-Hosting Guide - Docker · Jitsi Meet Handbook

The server is in docker-compose (standard docker-jitsi-meet config) on VM that does not know it’s own public IP (floating IP). Maybe requires some extra tweak that I have not yet found to allow for XMPP_WEBSOCKET.

The doc you refer to suggests disabling COLIBRI_WEBSOCKET. Based on my own experience, I’d say that this is not a good idea, breaking bandwidth estimation completely.

You’re clearly having websocket issues. If your JVB websockets are not working properly, only the lowest resolution layers will be requested (hence your experience). To confirm, if you check your connection stats, you will notice that a few stats are missing and if you check your browser console while hosting a meeting with 3 participants, you will see a bunch of websocket errors. The issue is not a “Broken bandwidth estimation”, your issue is a lack of configuration of the bridge websockets.