We have deployed a Docker version and Ubuntu version of Jitsi meet following the official guides. It works well, but have recently run into an issue on one particular device which we have not been able to solve.
The problem:
The client connects to a room and can see/hear himself, but has a black screen where other participants’ cameras are with no audio from anyone else. The error in the browser logs is below
After doing more testing, we have figured out that it is a network/firewall issue.
What we still cannot figure out is what the difference is between meet.jit.si (where everything works, no matter the network used) and the Jitsi Docker and Jitsi Ubuntu(where the network is an issue).
Thanks for the feedback. We have tested the Docker/Ubuntu deployments on AWS and another datacentre with no Linux(UFW) or external firewall(simply on an open public IP).
With the Docker deployment, everything is kept in docker, in the .env file the HTTPS port is changed from 8443 to 443, so the “web” Docker serves the end client. Meaning that there is no Nginx/Apache reverse proxy happening on the Linux host.
Do you have any other suggestions perhaps? Are you aware of any difference between the self-hosted(Docker/Ubuntu) versions of Jitsi and what is on meet.jit.si?
I noticed the same problem after moving from one bare-metal server to a cloud infrastructure with multiple machines. Maybe it has something to do with it
Hi there, i am also affected by this problem.
Although i am not sure if this can be broken down to certain users, as recently a group of users was affected that before was working.
This means that the setup sometimes/often works for 12+ users just fine, on other days not at all.
I would rather say it happens on “certain times”.
This setup is for a school and the random issues with broken video, which comes along with this error, are a bigger problem… and until now there is no clear way to reproduce the error, except that the session has to be important.
The setup is using docker and the upgrade header is set in the reverse proxy.
...
location /xmpp-websocket {
proxy_pass http://127.0.0.1:8000; # docker-jitsi-meet_web_1
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}
location /colibri-ws {
#proxy_pass http://127.0.0.1:8000; # docker-jitsi-meet_web_1
proxy_pass http://127.0.0.1:8000/colibri-ws/$1/$2$is_args$args; # changed to this after my reply here
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}
Thanks for the suggestions so far. Unfortunately still no luck - we are experiencing the exact same issue on more and more clients now who are connecting from their office networks.
What we have tried to solve by doing the following:
Updated this variable in .env ENABLE_XMPP_WEBSOCKET=1 and to 0
We have tried AWS and a different hosting provider that provides a plain public IP.
After many different tests again with Docker-Jitsi and Jitsi on Ubuntu it seems that the issue has been tracked down to the JVB. Here is a screenshot where you can see what happens when a client who does not have an issue connects to the JVB:
Compared to when a user who has no video or audio connects(you notice that this client never switches to a public IP, but rather remains on their private subnet)
