[Deployment Issue] Deployment of latest Jitsi versions result in app error

[orcu]

---

What is the problem? One-click apps does not work for recent Jitsi versions.
(Prepopulated version works like a charm. It is not fully compatible with the current Jitsi documentations though.)

Steps to reproduce the problem: Go to Jitsi in one click apps. Change version to latest, or any version above 5xxx. Install the app. (no errors) Start using the app (errors in js console)

Errors: Web app is not usable after installation as it fails to connect to the meeting and keeps reconnecting. Websocket related errors are seen in the js console, similar to the ones described here: https://community.jitsi.org/t/jitsi-meet-in-docker-container-websocket-error/88703.

Answers to the following questions if applicable: Ubuntu Focal, x86_64, 2gb Ram

[githubsaturn]

Because developers of 3rd party applications can change the requirements like this case, we lock down the embedded version rather than just blindly using the "latest" version.

In this case, there is a new Dockerfile for the new version of Jitsi. The old template is not compatible with the new version. https://github.com/jitsi/docker-jitsi-meet

One click apps are community maintained. Feel free to update the template to match the new requirements.

[donarek]

There is propably need to add web socket proxing to master nginx (the one managed by caprover), unfortunately I havnt yet delved deeper. The original caprover one click app for Jitsi Meet is imho bit strange anyway (port mapping, as mentioned by some of you guys discussing that pull request). Here are my notes and links to coresponding issues on jitsi github, if I get it working, I will post a fix.

https://github.com/jitsi/docker-jitsi-meet/issues/952 https://github.com/jitsi/docker-jitsi-meet/issues/977

location ^~ /colibri-ws {
    proxy_pass http://0.0.0.0:38000/colibri-ws;
    proxy_http_version 1.1;
    proxy_set_header Connection "upgrade";
    proxy_set_header Upgrade $http_upgrade;
    tcp_nodelay on;
}

# colibri (JVB) websockets
location ~ ^/colibri-ws/([a-zA-Z0-9-\.]+)/(.*) {
    proxy_pass http://$1:9090/colibri-ws/$1/$2$is_args$args;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    tcp_nodelay on;
}

# xmpp websockets
location = /xmpp-websocket {
    proxy_pass {{ .Env.XMPP_BOSH_URL_BASE }}/xmpp-websocket;
    proxy_http_version 1.1;

    proxy_set_header Connection "upgrade";
    proxy_set_header Upgrade $http_upgrade;

    proxy_set_header Host {{ .Env.XMPP_DOMAIN }};
    proxy_set_header X-Forwarded-For $remote_addr;
    tcp_nodelay on;
}

      # BOSH
      location /http-bind {
          proxy_pass      http://localhost:5280/http-bind;
          proxy_set_header X-Forwarded-For $remote_addr;
          proxy_set_header Host $http_host;
      }

HTTP_PORT=5010
HTTPS_PORT=5011
PUBLIC_URL=https://meet.example.org  # NOTE: use your actual domain :)
DOCKER_HOST_ADDRESS=meet.example.org
DISABLE_HTTPS=1  # NOTE: I want to use only HTTP between the container and nginx, potentially a huge security risk
ENABLE_LETSENCRYPT=0

XMPP_SERVER=prosody
XMPP_BOSH_URL_BASE=http://prosody:5280
JVB_PORT=30300
JVB_TCP_PORT=30301
JVB_TCP_MAPPED_PORT=30301
PUBLIC_URL= (full external url to your service, usually defined by an ingress)
DOCKER_HOST_ADDRESS= (ip address of one of your kubernetes cluster nodes, not your external ip address - otherwise it won't work inside your LAN, and the STUN server figures out your public ip anyways)

expose JVB port 30300

if (JVB_TCP_HARVESTER_DISABLED=true) expose 30301

XMPP_CROSS_DOMAIN: "true"

 location / { 
     proxy_pass http://127.0.0.1:8000; 
     proxy_set_header X-Forwarded-For $remote_addr; 
     proxy_set_header Host $http_host; 
 } 

 location /xmpp-websocket { 
     proxy_pass http://127.0.0.1:180/xmpp-websocket; 
     proxy_http_version 1.1; 
     proxy_set_header Upgrade $http_upgrade; 
     proxy_set_header Connection "upgrade"; 
     proxy_set_header Host $host; 
     tcp_nodelay on;
}

PORTS NAMES 0.0.0.0:4443->4443/tcp, 0.0.0.0:10000->10000/udp jitsi-docker_jvb_1 127.0.0.1:180->80/tcp, 127.0.0.1:1443->443/tcp jitsi-docker_web_1 <----- jitsi-docker_jicofo_1 5222/tcp, 5280/tcp, 5347/tcp jitsi-docker_prosody_1

[nullsumme]

Setting PUBLIC_URL helps to solve the reconnect issue. But still Jitsi is not working properly and I have no clue why. The video bridge is somehow not working.

JS Console:

[modules/statistics/AvgRTPStatsReporter.js] <dc.addNext>:  bandwidth_upload - invalid value for idx: 0 
[modules/statistics/AvgRTPStatsReporter.js] <dc.addNext>:  bandwidth_download - invalid value for idx: 0 

JVB Log:

2022-04-07T13:06:38.518787561Z INFO: verify if nominated pair answer again
2022-04-07T13:06:38.524436736Z Apr 07, 2022 1:06:38 PM org.ice4j.stack.NetAccessManager handleFatalError
2022-04-07T13:06:38.524480274Z SEVERE: Unexpected Error!
2022-04-07T13:06:38.524488061Z java.lang.NullPointerException
2022-04-07T13:06:38.524494030Z  at org.ice4j.socket.MergingDatagramSocket.initializeActive(MergingDatagramSocket.java:577)
2022-04-07T13:06:38.524501664Z  at org.ice4j.ice.ComponentSocket.propertyChange(ComponentSocket.java:176)
2022-04-07T13:06:38.524537800Z  at org.ice4j.ice.IceMediaStream.firePairPropertyChange(IceMediaStream.java:877)
....

I have no clue where the problem could be.

[mathieugp]

I am experiencing similar problems with Jitsi Meet docker stable-6865 or stable-7210.

@nullsumme : Can you check with netstat -tulpn | grep LISTEN on your CapRover if maybe the port mapping for 10000 udp and 4443 tcp (for jvb) are not only active for IPv6 ?

It is the case right now on my end and since IPv6 is not setup on the CapRover host, it simply cannot work. I would test this possible workaround myself right now:

https://serverfault.com/a/545734

... were it not for the fact that I am worried about affecting the other CapRover apps currently in production.

(Also, ideally I would rather enable IPv6 + IPv4 on the machine, but this would bring a whole set of changes that I am not ready to deal with just yet.)

[mathieugp]

Our instance of Jitsi Meet keeps failing as soon as a third participant enters the room even after disabling IPv6 completely on the Ubuntu 18.04 host running CapRover (through /etc/default/grub) to ensure that the port mappings are all IPv4... Back to square one. :-(

[mathieugp]

My colleague and I ended up trying to deploy via the official Docker Compose way from the Jitsi Meet handbook and behind a reverse proxy (Nginx Proxy Manager). The same problems appeared, so the culprit was NOT CapRover.

We finally figured it out when looking into the variables of /config/sip-communicator.properties inside the JVB container:

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=

Instead of having the host local network address for the first (10.x.x.x or 192.168.x.x) and the reverse proxy public address for the second, it contained the Docker network local container address (172.x.x.x) for the first and the host local network address for the second (10.x.x.x or 192.168.x.x).

We will get back here with a more complete answer for how to fix the CapRover Jitsi deployment.

[BigSnicker]

Any luck? The community-maintained version appears out-of-date, but not all of us have the expertise to fix it. We're trying to get a configuration that uses JWT but is closed to guests.