Mobile app not working with non-standard videobridge port

Some people I use meet with cannot use outgoing udp on port 10000 in their network, so I changed it to port 86 (with org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=86 in the videobridge properties)

This is working fine for browser clients, but not in the app (tested on android. I can connect to a meeting but I am not getting/sending video and audio).
The app was working fine with my server (using the standard port 10000) before this change though and still is if I change it back.

I then assumed the app is just always using port 10000 and tried redirecting traffic from port 10000 to port 86 on my machine with:

iptables -t nat -A PREROUTING -p udp --dport 10000 -j REDIRECT --to-port 86

but this is not working either. What could be the issue here?
Is there a way to tell the app to use my custom port? Or am I redirecting traffic from port 10000 to 86 wrong?

Info about my installation:

  • This is the guide I followed:
  • Since there already is a machine in my network hosting a webserver on ports 80/433 I chose port 85 for jitsi. I installed jitsi by following the guide, then changing the ssl listen port to 85 in the nginx config and the BOSH URL to include :85 after my FQDN in jitsi’s config.js. My meet instance is now available at and with this url it is working fine in the browser and also in the app (as long as the videobridge is running on port 10000)
  • My router is forwaring ports tcp/85 (for the https web interface) and udp/86 (for the videobridge) to the machine running the jitsi server (and also udp/10000). I did not open a port for http.
  • I have a let’s encrypt certificate for the server and reports the chain to be correct
  • I did not open the ports for the TURN/STUN servers and neither did I enable them in the config. P2P is turned off.
  • I am running the jitsi server on Ubuntu 20.04.1 LTS

The bridge is announcing port 10000 in the signalling and this is what is sent from jicofo to the clients.
So just forwarding like that will not work

You need to change jvb to listen to that port.

But isn’t this what org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=86 does?

I already did that and it makes the app stop working. If I change it to 10000 (or leave it at default, same thing), it works.

But I want the bridge on port 86, not 10000, so it works for my friends who can’t connect on udp 10000 because their firewall disallows it.

How do I get the app to work with the videobridge on port 86?

My suspicion is that it’s got something to do with me running the whole thing not on the default https port 443 but port 85 instead (and some config I did not change correctly and therefore the app not getting the message that it should connect to jvb on port 86 and not 10000).

I changed the port from 443 to 85 in the nginx site config and in the bosh url value in the meet config.js. Is there some place/config I missed where I need to change it as well?

Do I need to have a turn or stun server? Those are currently disabled.
Or do I need to configure jicofo or the harvester differently? I don’t know enough about jitsi here to know how to set those up.
Do I need to change the muc or focus values in config.js?

I also tried changing org.jitsi.videobridge.TCP_HARVESTER_PORT to 85 but to no avail.
Do I need to set Should it be my FQDN or my ip?

So, in summary:

  • I want the conference room to be on port 85, not 443 (reason: 80 and 443 are not free)
  • and I want the videobridge to use port 86, not 10000 (reason: my friends outgoing udp 10000 is blocked).
  • It’s all working fine like this except for the mobile app when the jvb port is not 10000 (but I can join the meeting and see participants, chat works as well, just no video/audio)

Do you see an error when you change it. Services that do not run as root to use privileged ports that are bellow 1024 need special permissions.

No, I am not seeing any errors
(It is not reporting any error when restarting the jitsi-videobridge2 service and there don’t seem to be errors in /var/log/jitsi/jvb.log. Are there other places I should check?)

I assume it’s working fine on port 86 though because:

  1. video/audio is working in the browser, it’s just the app that doesn’t work
  2. I am seeing activity on port 86 with ngrep udp port 86 and none on 10000
  3. it keeps working even if I don’t forward port 10000 on my router (so traffic on upd/10000 couldn’t even get to the jitsi machine, so it can’t be using that port). also netstat says nothing is actually running on port 10000

I have attached the latest messages from /var/log/jitsi/jvb.log and /var/log/jitsi/jicofo.log after restarting these services and then connecting with 2 clients and also my jvb config, maybe that helps?
(I have redacted some values: XX.XX.XX.XX is my public ip where I host the server (192.168.XX.JI locally) and the first connecting client (192.168.XX.C1 locally), YY.YY.YY.YY is the second client’s public ip. my.domain.tld is my FQDN)
jicofo.log (29.1 KB) jvb.log (42.6 KB) (749 Bytes)

So as I said, I can’t spot any errors, only things I noticed in the jvb log are:

  • wss://my.domain.tld:443/colibri-ws/ which won’t work since my jitsi web service is running on port 85 (433 is used by another machine). Could this be the issue? How do I fix this?
  • which port is that using? I am assuming 443. Do I need to change that to 85? How?


I have now managed to change the wss port to 85 (by changing :443 to :85 after the domain in the videobrige > websockets > domain value in /etc/jitsi/videobridge/jvs.conf) and now the websocket is working (confirmed by network inspector)

However this doesn’t change anything, it still doesn’t work with the app

Edit 2:

I monitored traffic on port udp/86 using tcpdump udp port 86 and it looks like the app is actually connecting and communicating with port 86 on my server. however, after the initial back and forth (which I assume to be some kind of handshake), there are no more packets sent.
I contrast, when I connect with two browser clients, where video works, I see the same kind of initial communication but it then continues to send traffic which I assume must be the actual videostream.