Simulcast and Websockets - An adventure

We have been struggling on and off for a while trying to get simulcast to work (properly, or even at all). Every time we set disablesimulcast to false (weird double negative by the way. surely it would make far more sense to have enableSimulcast: true/false), all participants streams were 180p and were never dynamically increased/decreased.

Just to clarify, we followed the installation instructions here: Ubuntu/Debian Installation Instructions & Repository

After digging through documentation (which is very sparse and doesn’t cover nearly as much as it should) and community forum threads (which are infinitely more useful than the documentation), we discovered that the apache config that is automatically installed by the jitsi-meet ubuntu package (haven’t checked other distros) misses out some very important lines relating to ProxyPass/ProxyReverse:

ProxyPass /xmpp-websocket ws://localhost:5280/xmpp-websocket
ProxyPassReverse /xmpp-websocket ws://localhost:5280/xmpp-websocket
ProxyPassMatch ^/colibri-ws/default-id ws://localhost:9090

You also have to enable the proxy_wstunnel apache module.

We stumbled upon these missing lines by complete luck from the jitsi-meet github page that had an example apache config (I would post it here however I’m limited to 2 links in one post). Without these, websocket functionality does not work. This means you don’t have things like calculations of round-trip times which I believe is crucial for simulcast to work.

I can see a lot of posts from other people with similar/the same issue. None had a resolution, and none that I’ve found mention websockets might be an issue, or are required, but it’s clear that they are.

I just thought I’d post this to try and save someone else the time and effort of figuring this out for themselves like I’ve had to.

Related links:

1 Like

for now you can simply use

openBridgeChannel : ‘datachannel’

and do nothing else configuration which will be okay to have dynamic resolution change but this config wont be supported in future so it is better advised to adopt ‘websocket’ instead of ‘datachannel’ but it is okay to use datachannel. even I saw here that the latest stable may use websocket by default and do default config for you.

if that works then you can do both to even optimize senders bandwidth (by supressing higher resolution layer that is not used on any other participant in that conference)

disableSimulcast: false,
enableLayerSuspension: true

If even now you are seeing that resolution are not what you are expecting and something is wrong then make sure

enableRemb: true,
enableTcc: true,

are set to true which actually stands for sender side and receiver side bandwidth congession controlling.
you can then even add

disableRtx: false,

to have better processing on client side.

Hope for the best :heart:

you can also take a look at this thread