I wish it was easier to self host, I really do. I tried 3 times over the last 2 months to host jitsi. It’s a ridiculously complicated web of software, and impossible for anyone new to this to figure out how it’s all supposed to work when it doesn’t.
First attempt was using the magical ‘curl |bash’ method on debian, which installed but I could never get 3-way video chat to work reliably.
Second attempt was with their docker-compose project. After much effort trying different branches and config changes (both officially documented, and suggested in various issue comments in their repo), I ended up with something where 2-way video chat didn’t work reliably, and 3-way didn’t work at all.
Third attempt was installing packages from AUR and hoping that I could figure out how it’s all supposed to work together so that I could get it to actually function. I got less far than the previous two attempts.
Also the option search did not show the jitsi options.
That said, the reviewers are being diligent but the PR is shaping up being super nice! The current blocker is to have some meaningful tests for the PR, which is difficult because you need to fake video input, do some screenshots, compare them or something like that.
I did rip the relevant parts from the PR and make them available separately here in my nur-packages repo.
I got it working using on my second attempt using docker-compose and traefik as a reverse proxy. I could write a blog post about my setup if you think that could be of any help.
That is a good thing to test since the two way calls don’t involve the brige. Which you probably know.
For me, I could reproduce problems by even just open the same conference in chrome/chromium three times or more. Only with the correct setup, I’d see the video feeds for all tiles in gallery view.
Jitsi Meet is easy to install on e.g. Debian by adding the correct repo (deb https://download.jitsi.org stable/) and installing the jitsi-meetpackage. This will pull in the required packages (jicofo, jitsi-meet-web, jitsi-meet-web-config, jitsi-meet-prosody) and suggests installing a turn server (jitsi-meet-turnserver). On installation you’ll be asked about what domain you want to use (give it a FQDN, i.e. somewhere.example.com instead of somewhere). Open up the firewall to UDP:10000 for Jitsi and whatever you use for XMPP,/BOSH/TURN/TURNS (I submitted a PR to get them to use the IANA-assigned ports for TURN/TURNS as that currently is a bit of a mess) but after that my experience is that it just works.
The basic features of jitsi works ok. Try debugging jibri (Xorg server with a custom linux kernel module for audio loopback, starting chromium, starting the javascript web client, recorded with ffmpeg and using PJSUA for providing an SIP stack) video encoding errors or enabling Web Tokens and that is another story.
As long as it work out of the box and you do not have to seek in the internals, it is easy.
Jibri (the optional recording/streaming component) however is a lot more painful. It requires java 8 (or else video recording doesn’t terminate properly. Use of Java 8 causes cert issues on jicofo if you use let’s encrypt as the adoptopenjdk8 certstore doesn’t have LE), lots of cert tweakery (the one I mentioned about adoptopenjdk8 earlier, if you use self signed certs, chrome itself doesn’t like self signed certs so you’ll either have to trust the cert or run chrome in an insecure way), a kernel with alsa loopback capture support (can’t remember the name of the kernel module, but basically -cloud kernels don’t work, and I had no success with getting it to work in a container) etc.
That is the whole thing: it is not a Web (HTTP) software: it is an XMPP software: a different protocol for which jitsi-meet is a web-to-xmpp gateway. :)
I managed to get Jitsi Meet working first time with the quick install instructions, however, I ended up spending days trying to get the JWT auth working which was incredibly frustrating.
In the end I scrapped my first attempt and found a post on the Jitsi forums which had step-by-step instructions for token auth with Ubuntu 18.04 and it worked like a charm. Here’s the link for anyone in a similar situation.
I am running a debian setup and it works fine with up to 6 parties. I have not tried more yet, but I see no reason why it should not work.
The thing is that you need more RAM. I started with a small vpc at hetzner cloud and it works for 1on1 Chat, but only because jitsi uses peer-to-peer for those. The moment a third party joins, you need at least 8GB ram. I upgraded my instance and it works fine now.
but I could never get 3-way video chat to work reliably.
Did you check the videobridge logs? The main difference between between 2 and 3 way calls is that the latter are using the videobridge and I had to fiddle around a bit with the way Jitsis Debian packaging handled hostnames and certificates. I have an ansible playbook for Jitsi Meet on Debian buster which I could clean up if that would be of any interest.
To have a video conference platform that is selfhosted and for which “end-to-end encryption” is not just a marketing term but actually a feature built together with “crypto enthusiasts” from the community is a true reason for celebration these days.
It works fine in Firefox, at least on the systems I’ve tested it with. There seem to be some problems related to choosing the correct camera on systems with more than one camera source but when I encountered these the result was the same in Chromium as well as in Firefox. Those problems were solved (for me) by adding constrains to config.js:
I stumbled upon this when searching for a peer to peer videoconferencing solutions. Seems to work very well.
I was mainly interested in reducing latency. Have anyone published any measurements between discord, zoom, skype, teams and jitsi?
I haven’t measured anything. Are you concerned about 1-1 chats or with many people? For 1-1, Jitsi at least uses WebRTC peering which should be really good if WebRTC manages to connect directly and not via a relay server.
Otherwise, Jitsi uses the strategy of relaying video streams instead of recoding them. That might mean more data down the pipe but as long as your bandwidth holds up, it might also be faster than other solutions. I noticed that my self-hosted server performs a bit better than the public instances. (well, it is barely loaded)
Jitsi is fantastic, I use it nearly everyday. But as @craftyguy said, the process for self-hosting this… could use some work. Until then meet.jit.si should do the job.
I wish it was easier to self host, I really do. I tried 3 times over the last 2 months to host jitsi. It’s a ridiculously complicated web of software, and impossible for anyone new to this to figure out how it’s all supposed to work when it doesn’t.
First attempt was using the magical ‘curl |bash’ method on debian, which installed but I could never get 3-way video chat to work reliably.
Second attempt was with their docker-compose project. After much effort trying different branches and config changes (both officially documented, and suggested in various issue comments in their repo), I ended up with something where 2-way video chat didn’t work reliably, and 3-way didn’t work at all.
Third attempt was installing packages from AUR and hoping that I could figure out how it’s all supposed to work together so that I could get it to actually function. I got less far than the previous two attempts.
Probably not much of a help to you but for others, NixOS just got support in release 20.03 and you should be able to use it like so:
Thanks. I don’t use NixOS, but maybe this is a great time to try it.
The PR wasn’t merged yet, as far as I can see:
https://github.com/NixOS/nixpkgs/pull/82920
Also the option search did not show the jitsi options.
That said, the reviewers are being diligent but the PR is shaping up being super nice! The current blocker is to have some meaningful tests for the PR, which is difficult because you need to fake video input, do some screenshots, compare them or something like that.
I did rip the relevant parts from the PR and make them available separately here in my nur-packages repo.
Ah bugger, sorry for some reason I thought it got merged a while ago!
I got it working using on my second attempt using docker-compose and traefik as a reverse proxy. I could write a blog post about my setup if you think that could be of any help.
Haven’t tried 3-way calls, yet…
That is a good thing to test since the two way calls don’t involve the brige. Which you probably know.
For me, I could reproduce problems by even just open the same conference in chrome/chromium three times or more. Only with the correct setup, I’d see the video feeds for all tiles in gallery view.
I did not know the bridge was not involved! I will test 3-way calls today.
Open 3 tabs and you should have 3-way calls.
Jitsi Meet is easy to install on e.g. Debian by adding the correct repo (
deb https://download.jitsi.org stable/) and installing thejitsi-meetpackage. This will pull in the required packages (jicofo, jitsi-meet-web, jitsi-meet-web-config, jitsi-meet-prosody) and suggests installing a turn server (jitsi-meet-turnserver). On installation you’ll be asked about what domain you want to use (give it a FQDN, i.e.somewhere.example.cominstead ofsomewhere). Open up the firewall toUDP:10000for Jitsi and whatever you use for XMPP,/BOSH/TURN/TURNS (I submitted a PR to get them to use the IANA-assigned ports for TURN/TURNS as that currently is a bit of a mess) but after that my experience is that it just works.The basic features of jitsi works ok. Try debugging jibri (Xorg server with a custom linux kernel module for audio loopback, starting chromium, starting the javascript web client, recorded with ffmpeg and using PJSUA for providing an SIP stack) video encoding errors or enabling Web Tokens and that is another story.
As long as it work out of the box and you do not have to seek in the internals, it is easy.
Yes! I didn’t think this wasn’t too difficult (sure could be a bit easier). Here are some tips we use: https://j11g.com/2020/05/04/jitsi-finetuning-and-customization-tips/
The official guide is fairly easy to follow IMO, and I never had issues on 3-way calls after installing it on debian buster: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart
Jibri (the optional recording/streaming component) however is a lot more painful. It requires java 8 (or else video recording doesn’t terminate properly. Use of Java 8 causes cert issues on jicofo if you use let’s encrypt as the adoptopenjdk8 certstore doesn’t have LE), lots of cert tweakery (the one I mentioned about adoptopenjdk8 earlier, if you use self signed certs, chrome itself doesn’t like self signed certs so you’ll either have to trust the cert or run chrome in an insecure way), a kernel with alsa loopback capture support (can’t remember the name of the kernel module, but basically -cloud kernels don’t work, and I had no success with getting it to work in a container) etc.
@craftyguy Have you seen this? I think it was posted here before.
https://matrix.org/blog/2020/04/06/running-your-own-secure-communication-service-with-matrix-and-jitsi
I hadn’t seen that. Thanks for sharing, I’ll read up on it. Maybe I’ll make a 4th attempt soon :)
That is the whole thing: it is not a Web (HTTP) software: it is an XMPP software: a different protocol for which jitsi-meet is a web-to-xmpp gateway. :)
I managed to get Jitsi Meet working first time with the quick install instructions, however, I ended up spending days trying to get the JWT auth working which was incredibly frustrating.
In the end I scrapped my first attempt and found a post on the Jitsi forums which had step-by-step instructions for token auth with Ubuntu 18.04 and it worked like a charm. Here’s the link for anyone in a similar situation.
I am running a debian setup and it works fine with up to 6 parties. I have not tried more yet, but I see no reason why it should not work.
The thing is that you need more RAM. I started with a small vpc at hetzner cloud and it works for 1on1 Chat, but only because jitsi uses peer-to-peer for those. The moment a third party joins, you need at least 8GB ram. I upgraded my instance and it works fine now.
Did you check the videobridge logs? The main difference between between 2 and 3 way calls is that the latter are using the videobridge and I had to fiddle around a bit with the way Jitsis Debian packaging handled hostnames and certificates. I have an ansible playbook for Jitsi Meet on Debian buster which I could clean up if that would be of any interest.
To have a video conference platform that is selfhosted and for which “end-to-end encryption” is not just a marketing term but actually a feature built together with “crypto enthusiasts” from the community is a true reason for celebration these days.
It’s very promising, but I’d hold off on the celebrations till they get it working in more than just Chrome.
It works fine in Firefox, at least on the systems I’ve tested it with. There seem to be some problems related to choosing the correct camera on systems with more than one camera source but when I encountered these the result was the same in Chromium as well as in Firefox. Those problems were solved (for me) by adding constrains to
config.js:From what I’ve heard, Firefox’s WebRTC implementation works fine in 1:1 calls but doesn’t handle multi-peer situations very well.
I stumbled upon this when searching for a peer to peer videoconferencing solutions. Seems to work very well. I was mainly interested in reducing latency. Have anyone published any measurements between discord, zoom, skype, teams and jitsi?
Discord is, unfortunately, the best in terms of performance from my experience. I still refuse to use it, regardless.
I haven’t measured anything. Are you concerned about 1-1 chats or with many people? For 1-1, Jitsi at least uses WebRTC peering which should be really good if WebRTC manages to connect directly and not via a relay server.
Otherwise, Jitsi uses the strategy of relaying video streams instead of recoding them. That might mean more data down the pipe but as long as your bandwidth holds up, it might also be faster than other solutions. I noticed that my self-hosted server performs a bit better than the public instances. (well, it is barely loaded)
I love the idea of jitsi, but we’ve been unable to use it with more than about 3 people without bandwidth issues.
Jitsi is fantastic, I use it nearly everyday. But as @craftyguy said, the process for self-hosting this… could use some work. Until then meet.jit.si should do the job.