Crash 1-3 seconds after second participant joins a room

Hi, after setting up a fresh checkout as of today, and minimal adjustments, I get stable operation until a second participant joins a room. It shows proper video and audio for 1-3 seconds for both participants, and then it crashes. It’s a pity, since it is seems to almost working nicely. Coincidentally, this project and behavior is starting to get famous.

The default setup defines JVB_ENABLE_APIS as none. Given this discussion, it ought to be something different, while a comment in env.example states:

#JVB_ENABLE_APIS=rest,colibri

which differs from the discussion, that states:

JVB_OPTS="--apis=xmpp,rest"

I’ve tried different combinations of xmpp, rest, colibri and confirmed, that the --api parameter of the process in the docker container dockerjitsimeet_jvb_1 matches.

Unfortunately, it’s not enough. The log is full of:

1993:jvb_1      | JVB 2020-03-25 16:40:37.191 SEVERE: [30] org.jitsi.videobridge.health.Health.log() Health check failed in 0ms:
2003:jvb_1      | JVB 2020-03-25 16:40:41.954 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2247:jvb_1      | JVB 2020-03-25 16:40:46.955 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2275:jvb_1      | JVB 2020-03-25 16:40:47.192 SEVERE: [30] org.jitsi.videobridge.health.Health.log() Health check failed in 1ms:
2347:jvb_1      | JVB 2020-03-25 16:40:51.956 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2372:jvb_1      | JVB 2020-03-25 16:40:56.957 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2396:jvb_1      | JVB 2020-03-25 16:40:57.192 SEVERE: [30] org.jitsi.videobridge.health.Health.log() Health check failed in 0ms:
2406:jvb_1      | JVB 2020-03-25 16:41:01.958 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2455:jvb_1      | JVB 2020-03-25 16:41:06.959 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275

which looks like being the culprit of this issue, but I haven’t even found a sign, what service the ominous port 5275 should be.

The docker layout is this:

          Name              Command   State                        Ports                      
----------------------------------------------------------------------------------------------
dockerjitsimeet_jicofo_1    /init     Up                                                      
dockerjitsimeet_jvb_1       /init     Up      0.0.0.0:10000->10000/udp, 0.0.0.0:4443->4443/tcp
dockerjitsimeet_prosody_1   /init     Up      5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp          
dockerjitsimeet_web_1       /init     Up      0.0.0.0:8443->443/tcp, 0.0.0.0:8008->80/tcp     

The http/https ports are a little strange, but this is behind a nginx reverse proxy, that handles ssl already. Full log is available here. The log shows ICE/STUN issues as well, but I’ve not touched those values from the defaults:

CONFIG=~/.jitsi-meet-cfg
HTTP_PORT=8008
HTTPS_PORT=8443
TZ=Europe/Berlin
PUBLIC_URL=https://meet.example.org
DOCKER_HOST_ADDRESS=192.168.123.10
XMPP_DOMAIN=meet.jitsi
XMPP_SERVER=xmpp.meet.jitsi
XMPP_BOSH_URL_BASE=http://xmpp.meet.jitsi:5280
XMPP_AUTH_DOMAIN=auth.meet.jitsi
XMPP_MUC_DOMAIN=muc.meet.jitsi
XMPP_INTERNAL_MUC_DOMAIN=internal-muc.meet.jitsi
XMPP_GUEST_DOMAIN=guest.meet.jitsi
XMPP_MODULES=
XMPP_MUC_MODULES=
XMPP_INTERNAL_MUC_MODULES=
JVB_BREWERY_MUC=jvbbrewery
JVB_AUTH_USER=jvb
JVB_AUTH_PASSWORD=passw0rd
JVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302
JVB_PORT=10000
JVB_TCP_HARVESTER_DISABLED=true
JVB_TCP_PORT=4443
JVB_ENABLE_APIS=xmpp,rest
JICOFO_COMPONENT_SECRET=s3cr37
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=passw0rd
JIGASI_XMPP_USER=jigasi
JIGASI_XMPP_PASSWORD=passw0rd
JIGASI_BREWERY_MUC=jigasibrewery
JIGASI_PORT_MIN=20000
JIGASI_PORT_MAX=20050
XMPP_RECORDER_DOMAIN=recorder.meet.jitsi
JIBRI_RECORDER_USER=recorder
JIBRI_RECORDER_PASSWORD=passw0rd
JIBRI_RECORDING_DIR=/config/recordings
JIBRI_FINALIZE_RECORDING_SCRIPT_PATH=/config/finalize.sh
JIBRI_XMPP_USER=jibri
JIBRI_XMPP_PASSWORD=passw0rd
JIBRI_BREWERY_MUC=jibribrewery
JIBRI_PENDING_TIMEOUT=90
JIBRI_STRIP_DOMAIN_JID=muc
JIBRI_LOGS_DIR=/config/logs
DISABLE_HTTPS=1

For completeness, the nginx setup (that handles other services with separate server_names well already):

server {
    if ($host = meet.example.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 0.0.0.0:80;
    listen [::]:80;
    server_name meet.example.org;
    server_tokens off; ## Don't show the nginx version number, a security best practice

    ## Individual nginx logs for this vhost
    access_log  /var/log/nginx/meet_access.log;
    error_log   /var/log/nginx/meet_error.log;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name meet.example.org;
    server_tokens off; ## Don't show the nginx version number, a security best practice
    #ssl_session_tickets off;
    
    ## Individual nginx logs for this vhost
    access_log  /var/log/nginx/meet_access.log;
    error_log   /var/log/nginx/meet_error.log;

    location / {
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://localhost:8008;
    }

    ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; # managed by Certbot
}

and the firewall has opened the relevant ports:

external (active)
  target: DROP
  icmp-block-inversion: no
  interfaces: eth1
  services: http https
  ports: 4443/tcp 10000/udp
  masquerade: yes

Any insights are much appreciated.