This blogpost is about running the server-side components for the jitsi video conferencing system on a Raspberry Pi.

It is not about using a Raspberry Pi as a client. If you want to connect to someone else’s jitsi instance (e.g. meet.jit.si), then you don’t need to install anything, assuming you’ve got a relatively modern browser.

tl;dr

It works.

I’m not sure how many participants, or simultaneous conferences, it would stomach, but jitsi running on a Raspberry Pi 4 with 4GB RAM handles a four-way conference just fine.

Hardware

I used a Raspberry Pi 4, with 4GB RAM, as that’s what I had available. I was sceptical whether just 4GB of RAM would be enough but, yes, so far, it’s been fine.

It’s got a PoE HAT on, to cut down on cables — it’s a small rack, with just the Ethernet cable going to it. It also means that, in theory, I can powercycle the port on the switch to reboot it if it goes badly wrong, but that would be a very much “last ditch attempt” thing, as I suspect the likelihood of corrupting the filesystem is pretty high.

Networking stuff

Part of the reason for the test was to experiment with giving the RPi a non-RFC1918 IPv4 address, so it was addressable directly over the Internet over IPv4 without NAT. NAT is a pain generally, but especially so with realtime voice / video stuff.

(IPv6 is public, non-NAT’d, but not everyone with whom I’ll use this will have IPv6, sadly.)

I used a specific subdomain for jitsi, and I set up the A and AAAA records ahead of the installation, so that the installation of the Let’s Encrypt TLS certificate would work.

I also sorted the firewall rules too, on the RPi itself and on the network firewall.

Software

What I did

I used Ubuntu 20.04 LTS server edition (so not desktop environment) as the base.

Installing jitsi was a little more involved that installing jitsi on something other than a Raspberry Pi, but it was still relatively straightforward.

(Obviously, “relatively straightforward” is subjective, and it rather presupposes familiarity with using a terminal/ssh, DNS, firewall config, and dealing with IP addresses (and NAT if necessary).)

I followed the normal instructions, but needed to make a slight tweak for ARM to get SCTP working.

For that, I followed the “Install SCTP from source” instructions here.

Because I had already installed a jdk installed, I needed to deal with that, else the mvn package command would fail:

sudo update-alternatives --config java export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-arm64/

And, with that, it “just worked”, with default HD video support. Both two person (peer-to-peer) and multi-way (not peer-to-peer) conferences work fine, as does screensharing (from the jitsi client Electron app; I haven’t tried it in-browser).

What I didn’t do

Because I’ve given the RPi a non-RFC1918 IPv4 address, I did not need to make the config changes necessary to deal with a NAT’d environment. If you do need to do this, make sure you do so, as it’s just not going to work — or, at least, work reliably — if you don’t.

I didn’t use the “secure domain” configuration this time — if you want to limit the ability to start rooms to authenticated users, then you’ll want to follow this too. Edit: I changed my mind pretty much immediately and did this.

I also haven’t tried intergrating it with a SIP gateway (jigasi) or setting up recording (jibri). I’d like to do the SIP integration at some point, so that people can phone in, rather than needing to use their browser, if they wish, but that’s decidedly non-trivial using my current PBX, and I don’t fancy running asterisk just for this. Dialling out from a room is much easier but, since I’m not using “secure domain”, that doesn’t seem like the smartest idea, even though I’m not publicising the server’s URL.

End to end encryption and jitsi

Jitsi is working on end to end encryption, but it’s highly browser-dependent at the moment. (And may always be that way, I guess.)

For now, it’s ends-to-middle encrypted but, since that “middle” – the RPi running jitsi — is under my control, physically and logically, I’m pretty comfortable with the overall level of security for most calls.

Why do you bother self-hosting, when there’s meet.jit.si, Teams, Zoom etc.?

Good question.

1. I want to. It was a fun experiment.
2. I can. I’ve got a decent Internet connection, the hardware, and the interest, so why not?
3. There’s less scope for other people prying on my traffic, monetising my data, policing the topics under discussion, stopping me from using the encryption I want to use, and so on.