Jitsi quick install and LXD in Ubuntu 18.04

For what I found webrtc requires https. I haven’t found any information regarding jitsi over http.
I am using nginx. I never used jetty before but heard it needs more resources.

Yes, WebRTC requires HTTPS. But you don’t need to do SSL twice. You can just handle SSL in an nginx instance and then proxy via HTTP to another one serving jitsi over HTTP.

Hm, what do I have to do to have it run without certificates?

If your nginx wasn’t reconfigured to serve Jitsi when you installed it, you must be using the builtin Jetty server. What do you have in /etc/jitsi/videobridge/sip-communicator.properties ?

Don’t get me wrong. I delete missconfigured containers and just start from scratch. Jitsi is running with nginx as webserver. It’s working. Im just interested in hosting it without re-encryption.

org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=focus@auth.jitsi.mydomain.com/.* org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<INTERNAL> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<PUBLIC> org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<INTERNAL> org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<PUBLIC> org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Just did the same journey and therefore want to leave my findings here for others:

  • As said before, you need a recent version of lxd, i.e. the snap version
  • Recent versions of the videobridge allow setting your own certificates during the installation- as we are using a proxy anyway, we can use the automatically generated, self-signed snakeoil certificate (/etc/ssl/private/ssl-cert-snakeoil.key + /etc/ssl/certs/ssl-cert-snakeoil.pem)
  • after the installation you can simply delete all https related stuff from the nginx config and serve it over http (instead of listen 4444 ssl http2; use listen 80; etc. in /etc/nginx/sites-available/YOURDOMAIN.conf). Or you leave it be - the nginx proxy server will accept it by default, though use more resources. I think there was some additional step that I forgot, maybe some other config already listening on port 80, but I deleted that. And it appears to work just fine over http.
  • Make you public proxy nginx server forward https to http on the chosen container / port (80 in the example above)
  • By now we don’t need the tcp port 4443 anymore, just the upd:10000 one. You can forward the port to the container via: lxc config device add <CONTAINERNAME> <SOMERANDOMDEVICENAME> proxy listen=udp:<PUBLICIPADDRESS>:10000 connect=udp:<CONTAINERIPADDRESS>:10000
  • then configure the videobridge like explained in the advanced section from https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md:
    • org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<CONTAINERIPADDRESS>
    • org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<PUBLICIPADDRESS>
    • org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES commented out / removed

That should work just fine

One more note: unfortunately it appears not to work when binding the udp port to 127.0.0.1 on the container - the container ip address needs to be used for some reason.

@rmader
I’ve used LXD for a long time and currently run SNAP LXD on Ubuntu 20.04LTS.
I launched an ubuntu/fossa container
installed Jitsi in the container
I can access Jitsi from the Host using Firefox or Chromium and I can see myself
from my webcam on jitsi
However, about every 30 seconds I see "You’ve been disconnected"

Did you encounter that also and if you did how did you resolve it?
thanks
brian

@bmullan: hej, sorry for the late answer. I do not see such behavior, but I have to note that I’m using the beta channel of jitsi - maybe that helps.

@rmader
by “beta” do you mean their “testing” version?

Yes

your problem has nothing to do with stable/unstable; I have currently a stable Jitsi and an ‘unstable’ aka nightly Jitsi in 2 20.04 containers and there is no problem with either.
This is definitely not a common problem on this forum and it could be that container config is the culprit. Maybe your default profile has restrictions ? Or you did some customization your forgot to talk about. Prosody and jicofo.log could be useful.

@gpatel-fr

I am using 20.04and SNAP LXD

You said:

This is definitely not a common problem on this forum

I’ve spent the last several days trying to get this to work and in my google searches I’ve seen alot of people stating the same problem(s) I have encountered and most are not even usingusing LXD as I am.

@gpatel-fr I am assuming you mean you are running Jitsi in 20.04 LXD containers?

My LXD container “configs” are just default as I’m just launching them as follows:

$ lxc launch ubuntu:f test

If I access the IP of the container I see jitsi but there is no webcam video.
If I click on “settings” I DO see my webcam output in the small setup box window

Did you do anything like map the host’s /dev/video0 into your container?

IMO that’s not the case; people are having the disconnect message when they are trying to open a conference, that is, 2 connections (and more often it’s when there is 3 connections). Crashing by just entering a room is not so common.

absolutely not; are you trying to access Jitsi by having a X11 session in the container ? I use standard X11 sessions or a phone, my containers are on an internet server (outside my personal network)

to access peripherals such as webcam or microphone from a browser you must be in a secure session, that is, TLS. You should have a certificate, even if it’s a self signed certificate for an internal access.

@gpatel-fr>

absolutely not; are you trying to access Jitsi by having a X11 session in the container ? I use standard X11 sessions or a phone, my containers are on an internet server (outside my personal network)

no, I have one server where the jitsi lxd container is running
and 2 laptops.

from the host where the Jitsi lxd container runs I get this response
and from both laptops I get the same response.

on the host where the container runs I’ve used LXD proxy device to map the ports to the container for those laptops to use to get to the container.

to access peripherals such as webcam or microphone from a browser you must be in a secure session, that is, TLS. You should have a certificate, even if it’s a self signed certificate for an internal access.

I am using a self signed cert and HTTPS on both firefox and chromium and both do the same thing.

I have never used the proxy device, I don’t know if it can do UDP. I use iptables (through ufw) to forward port 10000/udp, on the host I use nginx that is proxying the port 443 to the port 80 of the container (I have zapped all the secure part of the nginx in the container to leave only straight http). If you are leaving the TLS configuration of the jitsi container and using the LXD proxy to connect 443 port on the host to 443 port in the container it should work also I guess.

Edit: I forgot to say that in my config the setup host -> container is the equivalent of natting and as such I have setup videobridge configuration.

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=...private address...
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=...public address...

With all this I’m not yet sure of when you get problems; is it with only one connection, or with 2 ?

Yes I’ve made that change also…

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=…private address…
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=…public address…

I’ve tried to follow a couple different “guides” including:

**

https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart

**

I didn’t ask but I assumed you are running un-privilged containers.

yes
as I am not yet sure at all of what you did exactly or even how it crashes, at this time it’s appropriate to post my usual connection test:

(server)
sudo systemctl stop jitsi-videobridge2
nc -l 10000 -u

(workstation)
echo "123" | nc -u (your public address) 10000

in your case server means Jitsi container, and public address would be the LAN ip address of the host with the Jitsi container, of course.

If previous test works, also please provide the prosody (/var/log/prosody), jicofo and videobridge logs (/var/log/jitsi)

by the way… here is just one Jitsi community thread with alot of people reporting exactly what I am seeing:

ok… in my container named “jitsi”:

# nc -l 10000 -u

in my LXD Host:

echo “123” | nc -u 10.107.254.195 10000

back in my container this appears:

# nc -l 10000 -u
123

actually what I was saying was:

is 10.107.254.195 your LXD bridge address or your host IP address on your LAN (you should do the test from one of your laptops too)