Second participant can't connect, grey or red screens appear on both devices

Hi, thanks for the docker-compose solution, works like a charm! 😃 I tried to set up the deb/manual way but this is the only one that has resulted a working video.

However, the video feed only works if I’m the only one in the room, so it’s not that fun after all 😄

• When the second participant tries to join the room on web, we both get the grey reconnect countdown screen.
• When a mobile client tries to join a room created on web, the mobile gets the red screen, the web gets the grey screen.
• When a room is created on mobile and a second mobile tries to join, both get the red screen.

Here is my setup starting from a clean Ubuntu 18.04 LTS Cloud-Init KVM image (https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img) on Proxmox VE host, all commands run as root inside the VM:

Installing Docker

apt update
apt upgrade -y
apt remove docker docker-engine docker.io docker-compose
apt purge docker-ce

cd ~
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
cat /etc/apt/sources.list.d/docker.list
rm get-docker.sh 

uname -a
# Linux jitsi-meet 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

docker -v
# Docker version 18.06.1-ce, build e68fc7a
docker-compose version
# docker-compose version 1.22.0, build f46880fe
# docker-py version: 3.4.1
# CPython version: 3.6.6
# OpenSSL version: OpenSSL 1.1.0f  25 May 2017

systemctl status docker
# active (running)

Installing Jitsi

mkdir -p /opt/jitsi-config/
chmod a+w /opt/jitsi-config/
mkdir -p ~/github
git clone https://github.com/jitsi/docker-jitsi-meet.git ~/github/docker-jitsi-meet
cd ~/github/docker-jitsi-meet
cp env.example .env
cat .env
# replacing the config values to match my environment
sed -i -E 's/(CONFIG=).*/\1\/opt\/jitsi-config/g' .env
sed -i -E 's/(TZ=).*/\1MyContinent\/MyCity/g' .env
sed -i -E "s/(JVB_COMPONENT_SECRET=).*/\1$(openssl rand -hex 32)/g" .env
sed -i -E 's/(JVB_STUN_SERVERS=).*/\1my.own.stun.server:port/g' .env
sed -i -E "s/(JICOFO_COMPONENT_SECRET=).*/\1$(openssl rand -hex 32)/g" .env
sed -i -E "s/(JICOFO_AUTH_PASSWORD=).*/\1$(openssl rand -hex 32)/g" .env
sed -i -E 's/#?(DOCKER_HOST_ADDRESS=).*/\1192.168.1.3/g' .env
cat .env

# cleanup of old configs and containers if any
docker-compose kill
docker rm docker-jitsi-meet_jvb_1 docker-jitsi-meet_jicofo_1 docker-jitsi-meet_prosody_1 docker-jitsi-meet_web_1
rm -rf ~/.jitsi-meet-cfg  
rm -rf /opt/jitsi-config/*

docker-compose up -d
docker ps
# CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                                         NAMES
# bbc3ff069565        jitsi/jvb           "/init"             41 minutes ago      Up 39 minutes       0.0.0.0:10000->10000/udp                      docker-jitsi-meet_jvb_1
# aea6cce3f928        jitsi/jicofo        "/init"             41 minutes ago      Up 39 minutes                                                     docker-jitsi-meet_jicofo_1
# b75362a2a10b        jitsi/prosody       "/init"             41 minutes ago      Up 39 minutes       5222/tcp, 5269/tcp, 5280-5281/tcp, 5347/tcp   docker-jitsi-meet_prosody_1
# 2919f0690e92        jitsi/web           "/init"             41 minutes ago      Up 39 minutes       0.0.0.0:8000->80/tcp, 0.0.0.0:8443->443/tcp   docker-jitsi-meet_web_1
# later copypaste here than their actual start :D

chmod -R 0777 /opt/jitsi-config

I’m aware of this comment about storing configs outside of root-only access path, so I use a directory in /opt with all access provided as you can see above: https://github.com/jitsi/docker-jitsi-meet/issues/5#issuecomment-413805288 I’ve also found this comment about the absolute BOSH URL, tried it with and without the DOCKER_HOST_ADDRESS config commented but it didn’t help: https://github.com/jitsi/docker-jitsi-meet/issues/2#issuecomment-409202397

Jitsi is running behind an nginx reverse proxy that is configured to listen 443 ssl http2, it gets valid SSL certs from LE, has a single location / with proxy_pass http://192.168.1.3:8000. Port 443/tcp is open on WAN gateway and pointed to the proxy, 10000/udp is open and pointed to the Jitsi VM (192.168.1.3:10000/udp) just as the official image says:

Clients are latest Chrome on Linux or latest Jitsi Android apps. I must add that I’ve only tried to access https://myjitsi.domain.tld from inside the LAN on the computer but also tried to connect to it from mobile internet on the phones with same result.

Chrome doesn’t output any error on dev tools with the first participant (only complaining about a woff file but uses a fallback instead):

[Intervention] Slow network is detected. See https://www.chromestatus.com/feature/5636954674692096 for more details. Fallback font will be used while loading: https://myjitsi.domain.tld/fonts/jitsi.woff?94d075
F	@	jquery.min.js:2

When the second participant connects, an error appears for a couple of seconds until page reload:

[conference.js] <e.value>:  CONFERENCE FAILED: conference.videobridgeNotAvailable

On the page reload, there are more errors on the console:

Logger.js:125 [modules/xmpp/strophe.util.js] <Object.i.Strophe.log>:  Strophe: TypeError: Cannot read property 'getMemberRole' of null
    at r._onIncomingCallP2P (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:242696)
    at r.onIncomingCall (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:243454)
    at n.emit (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:96313)
    at a.value (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:738288)
    at s.Handler.run (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:23250)
    at https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:31567
    at Object.forEachChild (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:14907)
    at s.Connection._dataRecv (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:31400)
    at e.Bosh._onRequestStateChange (https://myjitsi.domain.tld/libs/lib-jitsi-meet.min.js?v=2942:2:50925)
Logger.js:125 [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>:  UnhandledError: null Script: null Line: null Column: null StackTrace:  Error: Strophe: error: Cannot read property 'getMemberRole' of null
    at Object.i.Strophe.log (strophe.util.js:89)
    at Object.fatal (strophe.js:2093)
    at Object._handleError (strophe.js:2005)
    at s.Handler.run (strophe.js:2558)
    at strophe.js:3822
    at Object.forEachChild (strophe.js:1522)
    at s.Connection._dataRecv (strophe.js:3810)
    at e.Bosh._onRequestStateChange (strophe.js:5559)
Logger.js:125 [modules/xmpp/strophe.util.js] <Object.i.Strophe.log>:  Strophe: error: Cannot read property 'getMemberRole' of null

Then this error repeats over and over on every page reload. If one client is reloaded before another, it shows the camera image and the whole room interface but then when the second connects, grey screen again.

On mobile, there is a flash of two participants in the room (two boxes of avatars with white border) but then the red screen happens on both devices.

What am I doing wrong or is missing? It seems Jitsi is working fine when used alone but not with two participants. Do you have some recommendations what or where to investigate further?

[damencho]

Your problem is that the video bridge is not connected to the xmpp server CONFERENCE FAILED: conference.videobridgeNotAvailable, you need to check the jvb logs in /var/log/jitsi/jvb.log and fix that problem.

[immanuelfodor]

I’ve just tried it out on the cloud VM, I needed to adjust the reverse proxy to the new port and https protocol in the local connection (https->proxy->http:8000->jitsi becomes https->proxy->https:8443->jitsi), and it works! 😃 With my own STUN server, it’s not, so I need some debugging there, but with the Google ones, it’s fine. I tried it with two tabs and also with one tab and a mobile, and it works in every case! 😃

I recommend a note in the readme to let fellow jitsi-meet-selfhosters know that they should try the https connection by default to keep them from a lot of headaches 😄

Thank you so much for the help and all the further idea to investigate. Closing this issue.