Always switching to low definition

Install & Config
#1

Hi,

I would need some help to troubleshoot something.
When starting a meeting, I’m always in HD but when someone join, we all drop to low definition even if we set it to HD!

Is there something else I’m missing?

EDIT: After a couple of test… when doing test from internal to internal (only with people on the LAN) we are using SD while in meeting but immediately after having some from “Internet” we are switching to “LD”

#2

This sounds like the internet participant has a low bandwidth, or a lot of packet losses.

#3

so it’s not related to a missing port in the firewall ?

#4

You might want to check to make sure you’re making websocket connections. Sounds like a websocket issue to me.

#5

@Freddie I’m not sure where/which file I can see which port I’m using… I know that i’m using 443 (nginx) but all the others ports, I’m not sure…

#6

These are the required ports:
https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart

  • 80 TCP - for SSL certificate verification / renewal with Let’s Encrypt
  • 443 TCP - for general access to Jitsi Meet
  • 10000 UDP - for general network video/audio communications
  • 22 TCP - if you access you server using SSH (change the port accordingly if it’s not 22)
  • 3478 UDP - for quering the stun server (coturn, optional, needs config.js change to enable it)
  • 5349 TCP - for fallback network video/audio communications over TCP (when UDP is blocked for example), served by coturn

Depending on which firewall you use you can check the rules with
iptables -L -n

PS: What’s your upload rate of your internet connection?

#7

If you upgraded an old installation to a recent stable version, it’s very probable that you don’t have websockets configured OK. Make a quick check of /etc/nginx/sites-enabled/YOUR-FQDN.conf and see if you have a location for “^/colibri-ws/…” if not, add it:

This is if you are using only one bridge on the same machine:

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

And this is if you use external JVBs:

location ~ ^/colibri-ws/([0-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;
}

If you use external JVBs, make sure that in jvb.conf on the JVB machine you put a different ID for each JVB, it’s very convenient to make them the same as the IP of the JVB machine, for example:

videobridge {
  http-servers {
    public {
        port = 9090
    }
  }
  websockets {
    enabled = true
    domain = "YOUR_DOMAIN:443"
    server-id = XX.XX.XX.XX (your JVB IP)
    tls = true
  }
}

You should then have the JVB listen on port TCP 9090, check this (on the JVB machine(s):

netstat -plant | grep 9090

#8

I never had any entries like that, neither on an old nor on a new installation, and as far as i know never ran into any issues (single host). Can that be?

#9

Well on a single host you only have the block above with 127.0.0.1:9090 as it’s connecting to localhost. And of course it’s a lot simple setup, unlike when you have external bridges and there is network involved between the components of the platform, etc.

#10

I think we found the problem!
In our old machine it was running behing nginx…

We create a new VM from scratch and it works perfectly now!