Doesn't work no matter what I put it on

I have tried to get Jitsi to work and it just doesn’t work. This latest installation was on a VPS with Ubuntu 20.04 and it still doesn’t work. No sound, no video even though the camera is on and working. On the other side it reports that mic and camera are muted when they are not. I followed the installation guide to the letter; even to the point of having to reload the server’s OS because I didn’t put the domain in correctly. It just doesn’t work. To the letter and yes, the ports listed are opened. To the letter. I have to question if this is ready for Prime time when I have installed three times on three different servers and it doesn’t work when it is claimed that it is just install and go. I looked at all the logs; no warnings, no errors, just lots of things that of course make no sense to me since I am not a Jitsi developer.

Well, clearly if you’re the only one having this issue, you can’t say it’s not “ready for Prime time”. There’s something wrong with your installation and it sounds like you might be making the same mistake over and over, that’s why multiple attempts at installation are not helping you. How did you install? What guide did you use?

First it was on a VM; so I thought issues with NAT and I tried several changes to the VM network. Then I moved to a VPS but they only offered older versions of Debian and Ubuntu and it still wasn’t working and asking here was told; no, you need the newer versions so I got a VPS with Ubuntu 20.04 but that didn’t make any difference so it isn’t the platform issue; same issues on all three platforms. Can connect, can start a conference but no one can share their video and sound; on the user side they see video but on the opposite side it states the user has their video and audio muted.

I think the install guide might need some updating. For one, just which ports need to be open on the firewall? Reading further down the install guide I see “Provided that all required ports are routed (forwarded) to the machine that it runs on. By default these ports are (TCP/443 or TCP/4443 and UDP/10000).” In the section on opening ports, port 4443 isn’t mentioned. Do I need to open port 4443 for incoming?

In the section on ports needed it lists:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 22/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp

I copied and pasted so I wouldn’t make a mistake on the ports. I like iptables but I used ufw so that I could follow the guide to the letter. In the nginx server block I see that localhost is making connections on 5280 and 9090. The install created the server block which is listed below:

server {
listen 80;
listen [::]:80;
server_name domain.tld;

location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root         /usr/share/jitsi-meet;
}
location = /.well-known/acme-challenge/ {
   return 404;
}
location / {
   return 301 https://$host$request_uri;
}

}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name domain.tld;

Mozilla Guideline v5.4, nginx 1.17.7, OpenSSL 1.1.1d, intermediate configuration

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;  # about 40000 sessions
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=63072000" always;

ssl_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;

root /usr/share/jitsi-meet;

# ssi on with javascript for multidomain variables in config.js
ssi on;
ssi_types application/x-javascript application/javascript;

index index.html index.htm;
error_page 404 /static/404.html;

gzip on;
gzip_types text/plain text/css application/javascript application/json image/x-icon application/octet-stream application/wasm;
gzip_vary on;
gzip_proxied no-cache no-store private expired auth;
gzip_min_length 512;

location = /config.js {
    alias /etc/jitsi/meet/domain.tld-config.js;
}

location = /external_api.js {
    alias /usr/share/jitsi-meet/libs/external_api.min.js;
}

#ensure all static content can always be found first
location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
{
    add_header 'Access-Control-Allow-Origin' '*';
    alias /usr/share/jitsi-meet/$1/$2;

    # cache all versioned files
    if ($arg_v) {
      expires 1y;
    }
}

# 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;
}

# xmpp websockets
location = /xmpp-websocket {
    proxy_pass http://127.0.0.1:5280/xmpp-websocket?prefix=$prefix&$args;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    tcp_nodelay on;
}

# colibri (JVB) websockets for jvb1
location ~ ^/colibri-ws/default-id/(.*) {
   proxy_pass http://127.0.0.1:9090/colibri-ws/default-id/$1$is_args$args;
   proxy_http_version 1.1;
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "upgrade";
   tcp_nodelay on;
}

location ~ ^/([^/?&:'"]+)$ {
    try_files $uri @root_path;
}

location @root_path {
    rewrite ^/(.*)$ / break;
}

location ~ ^/([^/?&:'"]+)/config.js$
{
   set $subdomain "$1.";
   set $subdir "$1/";

   alias /etc/jitsi/meet/domain.tld-config.js;
}

#Anything that didn't match above, and isn't a real file, assume it's a room name and redirect to /
location ~ ^/([^/?&:'"]+)/(.*)$ {
    set $subdomain "$1.";
    set $subdir "$1/";
    rewrite ^/([^/?&:'"]+)/(.*)$ /$2;
}

# BOSH for subdomains
location ~ ^/([^/?&:'"]+)/http-bind {
    set $subdomain "$1.";
    set $subdir "$1/";
    set $prefix "$1";

    rewrite ^/(.*)$ /http-bind;
}

# websockets for subdomains
location ~ ^/([^/?&:'"]+)/xmpp-websocket {
    set $subdomain "$1.";
    set $subdir "$1/";
    set $prefix "$1";

    rewrite ^/(.*)$ /xmpp-websocket;
}

}

The firewall settings:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To Action From


80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
10000/udp ALLOW IN Anywhere
22/tcp ALLOW IN Anywhere
3478/udp ALLOW IN Anywhere
5349/tcp ALLOW IN Anywhere
80/tcp (v6) ALLOW IN Anywhere (v6)
443/tcp (v6) ALLOW IN Anywhere (v6)
10000/udp (v6) ALLOW IN Anywhere (v6)
22/tcp (v6) ALLOW IN Anywhere (v6)
3478/udp (v6) ALLOW IN Anywhere (v6)
5349/tcp (v6) ALLOW IN Anywhere (v6)

do a few basic tests

  • test if jvb is running and listening:
    systemctl status jitsi-videobridge2
    sudo ss -tapnu | grep 10000 -> you should get at least one process
    if these tests are not good, stop here and post the jvb.log file
    if yes:

  • check if port 10000 connectivity is good:

(server)
sudo systemctl stop jitsi-videobridge2
nc -l 10000 -u
(workstation)
echo "123" | nc -u (your public address) 10000

I didn’t think about netcat. No result.

I did nmap

Nmap scan report for xxx.xxx.xxx.xxx
Host is up (0.086s latency).
PORT STATE SERVICE
10000/udp open|filtered ndmp

Is there another way to actually test if data can move through port 10000 other that netcat?

apt-get install ngrep
ngrep -q '.*' udp port 10000

do you mean that 123 did not appear on the server console ? if this is the case, connectivity does not work. nmap is no definitive proof that it works. Such problems are common on VMs (and quite a few of VPS are really VMs, and you have to actually enable the connection on the provider management console)

I have never been able to get netcat to work; I have tried it for other projects. No, 123 did not appear. What you said about the VPS may be the case. I will contact the provider of the VPS and see how they are handling the virtualised connections. My main server is CentOS 8 and I didn’t really want to try and go through a manual install to get it to work; the idea was to test it on the VPS and then I may just redo the server and move to Ubuntu.

I just logged into the provider of the VPS to send a message and noticed they had a firewall in place in the console. I have never seen that before; so there was a firewall in front of the VPS and it only had 80, 22, and 443 opened. I installed ufw on the VPS itself but the provider had an external firewall to the VPS. I guess this explained why I got conflicting results on tests.

My apologies; this is a new one to me.

this is quite common, one of my VPS has this ‘feature’ and I still manage to forget it from time to time and search why something does not work. You are definitely not the first to fall for that here.