I had a running Jitsi Meeting on my Raspberry/Ubuntu behind a Router (Fritz!Box) with NAT until February 21. After updating to Ubuntu 20.04.2 and/or Jitsi nothing worked again.
In the last 6 weeks I tried over 20 of fresh installations according the Jitsi installation guide and trying many different hints. We also tested two different infra stuctures. Always the same result:
Within the LAN (Intranet) 2 participants can join a meeting with video and audio. With a third participant, everybody sees only its own video and the others as a circle.
Starting one participant within the LAN and one from outside (Internet) both see only their own video.
UDP/10000 is open
Here are the log files just after first connection. I cannot interpret them.
jicofo.log (54.3 KB) jvb.log (98.5 KB) prosody.log (11.1 KB) jicofo.log (54.3 KB) jvb.log (98.5 KB) prosody.err.txt (568 Bytes) prosody.log (11.1 KB)
Maybe after the update your local ip of the machine changed to 192.168.178.22 and the settings on the router still forward 10000 udp to the old address.
I see in the jvb log that it successfully discovered its public address.
No change of IP.
The fresh installations use all this IP.
Hum, I just noticed you are using java14. Try with java 11, does that change anything?
I tested with jdk8 and jdk11, jdk14 was installed by the jitsi-installation.
If okay, can you try reinstalling with this script. Nothing special, but it makes sure no step is missed.
Btw it won’t take much of your time/effort.
Thank you for your support, but the given script doesn’t solve the problem too. I couldn’t even start a session. Here the logs:
jicofo.log.txt (10.8 KB) jvb.log.txt (53.3 KB) prosody.err.txt (568 Bytes) prosody.log.txt (8.7 KB)
Btw: Setting a PUBLIC_IP is not useful because it is changed every day. In my first working installation this was not necessary. I did it just for testing.
It would be useful to know if anybody had a similar installation scenario for the server that works:
Raspberry + Ubuntu + Jitsi server
behind a NAT, that changes every day its public IP.
You need to restart jvb when public IP changes and make sure this line is in the jvb config: jitsi-videobridge/postinst at 114f918568dfca26311bc2bdd2b9a7f3f568d256 · jitsi/jitsi-videobridge · GitHub
Can you please explain how to use this link?
Behind the link is a script, I have a /etc/jitsi/jvb.config, so how looks the line?
Sorry that I’m asking again.
Klicking to the link I now saw following line marked within the script:
echo “org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443” >> $NEW_JITSI_CONFIG
Shall this line to be added to jvb.conf ???
I can not imagine …
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443 you can add it in sip-commucator.properties
I don’t have handy an example for jvb.conf
So when your ip changes, just restart jvb and everything should start working again.
Sorry, I forget to tell that the line concerned was contained just from the beginning. So no other result.
Sorry I lost track of what we are talking about …
So if your public ip is changing, restart jvb, make sure you see the correct public address in the logs, test it and see it does not work, then do a test to verify that port udp 10000 is correctly forwarded and you see packets received, here is how to do that: Tip: how to check UDP/10000 connectivity
That’s what I already did, many times, from Intranet and Internet. I wrote it when starting this thread: Port 10000 is open.
A friend of mine tried the same installation: Ubuntu/Jitsi on Raspberry Pi4 behind a Fritz!Box as NAT-Router. He has the same result like me.
So I think it would be advisable if anybody who is familiar with the Jitsi development runs and tests this configuration.
But you did the test from the examples, listening on the jvb and starting the client from another network from internet?
Yep asking, as there are tons of people in the forum which say 10000 is open, and they mean just the firewall on the bridge, which is not enough. In the case you have a router infront of it, you need to do port forwarding there.
There is no way to test that deployment as you need user & pass to test it.