No Audio / Video - RaspPi4 2gb - Ubuntu 18.04.4 LTS / 64-bit

I installed a clean copy of Ubuntu 18.04.4 LTS - 64 bit. Followed the directions here:

I can open a room from outside my LAN. Letsencrypt is all set. The video preview on my device works. I can password protect the room. Others can connect to the room … but when they do:

I see the other user connect, and their icon and name appears. No video, no audio. On their device it shows that their audio is turned on. On my device their audio appears disabled/muted.

On their device, the same, but in reverse: They see their preview, their audio is on. They cannot see me, just my icon and name, and my audio/video appear disabled.

When I send a text message to the room, it works. Where do I go from here? Thanks!

EDIT: DMZ’ing the server makes no difference.


I have seen several posts where people had misunderstood this part:<Local.IP.Address><Public.IP.Address>

somehow managing to use it like that:<><>

the < and > should not be included, it should be

Having this when i connect with the IP or the wrong hostname.
Don’t know a solution yet, exept use the right hostname.

Thank you @gpatel-fr … unfortunately, that’s not it. I have the correct values entered, without <> brackets.

Maybe a bit of debugging with tcpdump or tshark could help ?
sudo tcpdump -i udp and port 10000
should show packets. If it’s not the case, check the network config (firewall, nat)
if yes, the logs (/var/log/jitsi (jicofo/jvb)) could be of interest.

I used tcpdump, but what worked for me was: sudo tcpdump -i eth0 udp and port 10000
0 packets captured
0 packets received by filter
0 packets dropped by kernel

The Ubuntu firewall, ufw, is disabled. Using " sudo ufw status verbose I get Status: inactive. Regardless, if I test this on two devices on the same LAN, the result is the same.

What does it mean if tcpdump isn’t seeing any udp 10000 traffic on two devices in LAN?

Yes that’s it of course, the forum software ate my attempt to represent a generic network card name using brackets.

You are saying that if you capture on a computer connecting to the server you don’t see UDP packets going to a port 10000 ? If yes take a look at the javascript console of your browser and at the server logs. Maybe try to disable p2p on the server to see if this changes something at the problem (file /etc/jitsi/meet/(your url)-config.js. Going back to your first post you say that you access from outside the LAN and from inside. Generally speaking It’s a difficult setup in fact, where the server name can indeed make all the difference.
I have never tried to do that with Jitsi, but with other kind of software it was necessary to do a split DNS, where the internal DNS was emulating the true external DNS so that internally the public name was used but redirecting to the internal IP address (unless your server has already a public IP address and is addressed as such by the internal clients of course)

@Stefan1 that is likely to be unrelated to the OP.
All browsers now do not allow you to load resources from different pages, except if some headers have been set (see ). The server name is set at several places in your configuration. If you connect with a different name that resolves to the same address, I’d guess you would see a message similar to this in your console log:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://<IP_or_other_name>/http-bind?room=<room_name>. (Reason: CORS request did not succeed).

I was running that on the server with no packets. I ran it on the client and same result.

That is true, and the ultimate goal. However, for the latest round of testing, I used two devices on the same LAN as the server, with the same result. I ran an nmap scan of the server (from inside the LAN) and I do see udp port 10000 open. Curiously, tcp port 4444 is open but not 4443.

What am I looking for in the javascript console and server logs?

that’s difficult to say because the potential range of problems is large.
I’d search at words like ‘Error’ or ‘Severe’ -even there it’s not easy to say because of possible translation efforts in logging :frowning:

At third thought, I’d tend to think it would be wise to not overlooking the possible arch problem: Raspi 4 is an ARM architecture and as such probably not included in the jitsi project tests. I have seen reports of success using a Raspi 4, but it’s not possible to exclude that something could have broken, so a good move could be to spin a VM on an Intel based computer, install the thing and look if it works better, use the opportunity to actually a simple internal deployment (not attempt to do a split DNS), it’s always easier to have a working setup even if it’s not the final goal and work from there to make it better.

With two participants and default configuration, peer-to-peer mode will be used. You might want to try to enforce using the videobridge by setting p2p: { enabled: false ... } in your “-config.js”.

So, I needed to get a production environment up for yesterday, so I spun up a VM, installed it on Ubuntu 18 and it worked. (I did disable the P2P function). Had to also set p2pTestMode: false in the -config.js

Now that it’s taken care of, I’d be happy to try and get the Pi4 going. thanks for your help thus far.

So as a recap, I’ve installed Jitsi-meet through Apt-get, on a rPi4, using the same instructions as I used for the Ubuntu 18 VM. No luck. Any further suggestions are appreciated … just looking to tease this out for others who might be trying to set it up on a rPi, my actual need is over. Thanks!