Jitsi Meet install on a Raspberry Pi 4 with Ubuntu Server 20.04. This guide helps you host your own Jitsi server on a Raspberry Pi 4B. It is adapted from Jitsi's quick install guide and the Jitsi on ARM guide written by crouchingtigerhiddenadam.
In order to quickly run Jitsi Meet on a machine running Docker and Docker Compose,follow these steps:
Download and extract the latest release. DO NOT clone the git repository. See below if you are interested in running test images.
.envfile by copying and adjusting
Set strong passwords in the security section options of
.envfile by running the following bash script
- For linux:
- For Windows:
docker-compose up -d
Access the web UI at
https://localhost:8443(or a different port, in case you edited the compose file).
I'm trying to install jitsi-meet on my debian testing, but I've same dependency issue that I can't understand. This is the problem. How to install and configure Jitsi video conferencing server on Ubuntu. How to install Windows Server 2022 on VMware Workstation. DMZ Jitsi appliance on VMWare pfSense Internet LAN Same pfSense of Jitsi Internet. PfSense manaja mas de una red en su LAN interface. Jitsi server esta en un Debian 9, detras de un pfSense router con HA Proxy. El firewall en Jitsi appliance esta apagado. Ports 80 y 443 son administrados por el HAProxy del pfSense.
Note that HTTP (not HTTPS) is also available (on port 8000, by default), but that's e.g. for a reverse proxy setup;direct access via HTTP instead HTTPS leads to WebRTC errors such as Failed to access your microphone/camera: Cannot use microphone/camera for an unknown reason. Cannot read property 'getUserMedia' of undefined or navigator.mediaDevices is undefined.
If you want to use jigasi too, first configure your env file with SIP credentialsand then run Docker Compose as follows:
If you want to enable document sharing via Etherpad, configure it and run Docker Compose asfollows:
If you want to use jibri too, first configure a host as described in JItsi BRoadcasting Infrastructure configuration sectionand then run Docker Compose as follows:
or to use jigasi too:
Testing development builds
Download the latest code:
The code in
master is designed to work with the unstable images. Do not run it with release images.
Build your own images:
Running unstable images
Every day a new 'unstable' image build is uploaded. You can test them by getting the YAML files from the repository and changing
ustable-YYYY-MM-DD for the unstable images of a specific day.
This setup used to have default passwords for internal accounts used across components. In order to make the default setupsecure by default these have been removed and the respective containers won't start without having a password set.
Strong passwords may be generated as follows:
./gen-passwords.shThis will modify your
.env file (a backup is saved in
.env.bak) and set strong passwords for each of therequired options. Passwords are generated using
openssl rand -hex 16 .
DO NOT reuse any of the passwords.
A Jitsi Meet installation can be broken down into the following components:
- A web interface
- An XMPP server
- A conference focus component
- A video router (could be more than one)
- A SIP gateway for audio calls
- A Broadcasting Infrastructure for recording or streaming a conference.
The diagram shows a typical deployment in a host running Docker. This projectseparates each of the components above into interlinked containers. To this end,several container images are provided.
The following external ports must be opened on a firewall:
80/tcpfor Web UI HTTP (really just to redirect, after uncommenting
443/tcpfor Web UI HTTPS
4443/tcpfor RTP media over TCP
10000/udpfor RTP media over UDP
20000-20050/udp for jigasi, in case you choose to deploy that to facilitate SIP access.
E.g. on a CentOS/Fedora server this would be done like this (without SIP access):
- base: Debian stable base image with the S6 Overlay for process control and theJitsi repositories enabled. All other images are based on this one.
- base-java: Same as the above, plus Java (OpenJDK).
- web: Jitsi Meet web UI, served with nginx.
- prosody: Prosody, the XMPP server.
- jicofo: Jicofo, the XMPP focus component.
- jvb: Jitsi Videobridge, the video router.
- jigasi: Jigasi, the SIP (audio only) gateway.
- etherpad: Etherpad, shared document editing addon.
- jibri: Jibri, the broadcasting infrastructure.
Jitsi Meet uses XMPP for signaling, thus the need for the XMPP server. The setup providedby these containers does not expose the XMPP server to the outside world. Instead, it's keptcompletely sealed, and routing of XMPP traffic only happens on a user-defined network.
The XMPP server can be exposed to the outside world, but that's out of the scope of thisproject.
The configuration is performed via environment variables contained in a
.env file. Youcan copy the provided
env.example file as a reference.
|Directory where all configuration will be stored||/opt/jitsi-meet-cfg|
|System Time Zone||Europe/Amsterdam|
|Exposed port for HTTP traffic||8000|
|Exposed port for HTTPS traffic||8443|
|IP address of the Docker host, needed for LAN environments||192.168.1.1|
|Public URL for the web service||https://meet.example.com|
NOTE: The mobile apps won't work with self-signed certificates (the default).See below for instructions on how to obtain a proper certificate with Let's Encrypt.
Let's Encrypt configuration
If you plan on exposing this container setup to the outside traffic directly andwant a proper TLS certificate, you are in luck because Let's Encrypt support isbuilt right in. Here are the required options:
|Enable Let's Encrypt certificate generation||1|
|Domain for which to generate the certificate||meet.example.com|
|E-Mail for receiving important account notifications (mandatory)||[email protected]|
In addition, you will need to set
HTTP_PORT to 80 and
HTTPS_PORT to 443. You might also consider to redirect HTTP traffic to HTTPS by setting
Let's Encrypt rate limit warning: Let's Encrypt has a limit to how many times you can submit a requestfor a new certificate for your domain name. At the time of writing, the current limit is five new (duplicate)certificates for the same domain name every seven days. Because of this, it is recommended that you disable theLet's Encrypt enviroment variables from
.env if you plan on deleting the
.jitsi-meet-cfg folder. Otherwise, youmight want to consider moving the
.jitsi-meet-cfg folder to a different location so you have a safe place to findthe certificate that already Let's Encrypt issued. Or do initial testing with Let's Encrypt disalbed, then re-enableLet's Encrypt once you are done testing.
For more information on Let's Encrypt's rate limits, visit:https://letsencrypt.org/docs/rate-limits/
SIP gateway configuration
If you want to enable the SIP gateway, these options are required:
|SIP URI for incoming / outgoing calls||[email protected]|
|Password for the specified SIP account||passw0rd|
|SIP server (use the SIP account domain if in doubt)||sip2sip.info|
|SIP server port||5060|
Display Dial-In information
|URL to the JSON with all Dial-In numbers||https://meet.example.com/dialin.json|
|URL to the API for checking/generating Dial-In codes||https://jitsi-api.jitsi.net/conferenceMapper|
The JSON with the Dial-In numbers should look like this:
JItsi BRoadcasting Infrastructure (Jibri) configuration
Before running Jibri, you need to set up an ALSA loopback device on the host. This will notwork on a non-Linux host.
For CentOS 7, the module is already compiled with the kernel, so just run:
NOTE: If you are running on AWS you may need to reboot your machine to use the generic kernel insteadof the 'aws' kernel. If after reboot, your machine is still using the 'aws' kernel, you'll need to manually update the grub file. So just run:
If you want to enable Jibri these options are required:
|Enable recording conference to local disk||1|
Extended Jibri configuration:
|Internal recorder user for Jibri client connections||recorder|
|Internal recorder password for Jibri client connections||passw0rd|
|Directory for recordings inside Jibri container||/config/recordings|
|The finalizing script. Will run after recording is complete||/config/finalize.sh|
|Internal user for Jibri client connections.||jibri|
|Prefix domain for strip inside Jibri (please see env.example for details)||muc|
|MUC name for the Jibri pool||jibribrewery|
|MUC connection timeout||90|
|Directory for logs inside Jibri container||/config/logs|
For using multiple Jibri instances, you have to select different loopback interfaces for each instance manually.
/home/jibri/.asoundrcinside a docker container.
Default the first instance has:
To setup the second instance, run container with changed
Also you can use numbering id for set loopback interface. The third instance will have
.asoundrc that looks like:
Authentication can be controlled with the environment variables below. If guestaccess is enabled, unauthenticated users will need to wait until a user authenticatesbefore they can join a room. If guest access is not enabled, every user will needto authenticate before they can join.
|Enable guest access||1|
|Select authentication type (internal, jwt or ldap)||internal|
The default authentication mode (
internal) uses XMPP credentials to authenticate users.To enable it you have to enable authentication with
ENABLE_AUTH and set
internal,then configure the settings you can see below.
Internal users must be created with the
prosodyctl utility in the
prosody container.In order to do that, first, execute a shell in the corresponding container:
Once in the container, run the following command to create a user:
Note that the command produces no output.
To delete a user, run the following command in the container:
To list all users, run the following command in the container:
Authentication using LDAP
You can use LDAP to authenticate users. To enable it you have to enable authentication with
ldap, then configure the settings you can see below.
|URL for ldap connection||ldaps://ldap.domain.com/|
|LDAP base DN. Can be empty.||DC=example,DC=domain,DC=com|
|LDAP user DN. Do not specify this parameter for the anonymous bind.||CN=binduser,OU=users,DC=example,DC=domain,DC=com|
|LDAP user password. Do not specify this parameter for the anonymous bind.||LdapUserPassw0rd|
|LDAP authentication method.||bind|
|LDAP protocol version||3|
|Enable LDAP TLS||1|
|Set TLS ciphers list to allow||SECURE256:SECURE128|
|Require and verify LDAP server certificate||1|
|Path to CA cert file. Used when server certificate verification is enabled||/etc/ssl/certs/ca-certificates.crt|
|Path to CA certs directory. Used when server certificate verification is enabled.||/etc/ssl/certs|
|Enable START_TLS, requires LDAPv3, URL must be ldap:// not ldaps://||0|
Authentication using JWT tokens
You can use JWT tokens to authenticate users. To enable it you have to enable authentication with
jwt, then configure the settings you can see below.
|Application secret known only to your token||my_jitsi_app_secret|
|(Optional) Set asap_accepted_issuers as a comma separated list||my_web_client,my_app_client|
|(Optional) Set asap_accepted_audiences as a comma separated list||my_server1,my_server2|
|(Optional) Set asap_keyserver to a url where public keys can be found||https://example.com/asap|
|(Optional) Allow anonymous users with no JWT while validating JWTs when provided||0|
|(Optional) Controls which module is used for processing incoming JWTs||token|
|(Optional) Controls which module is used for validating JWTs||token_verification|
This can be tested using the jwt.io debugger. Use the following sample payload:
Shared document editing using Etherpad
You can collaboratively edit a document via Etherpad. In order to enable it, set the config options below and runDocker Compose with the additional config file
Here are the required options:
|Set etherpad-lite URL||http://etherpad.meet.jitsi:9001|
If you want to enable the Transcribing function, these options are required:
|Enable Jigasi transcription in a conference||1|
For setting the Google Cloud Credentials please read https://cloud.google.com/text-to-speech/docs/quickstart-protocol section 'Before you begin' paragraph 1 to 5.
These configuration options are already set and generally don't need to be changed.
|Internal XMPP domain||meet.jitsi|
|Internal XMPP domain for authenticated services||auth.meet.jitsi|
|Internal XMPP server name xmpp.meet.jitsi||xmpp.meet.jitsi|
|Internal XMPP server URL for BOSH module||http://xmpp.meet.jitsi:5280|
|XMPP domain for the MUC||muc.meet.jitsi|
|XMPP domain for the internal MUC||internal-muc.meet.jitsi|
|XMPP domain for unauthenticated users||guest.meet.jitsi|
|Domain for the jibri recorder||recorder.meet.jitsi|
|Custom Prosody modules for XMPP_DOMAIN (comma separated)||info,alert|
|Custom Prosody modules for MUC component (comma separated)||info,alert|
|Custom Prosody modules for internal MUC component (comma separated)||info,alert|
|Custom prosody modules to load in global configuration (comma separated)||statistics,alert|
|Custom configuration string with escaped newlines||foo = bar;nkey = val;|
|Container restart policy||defaults to |
|XMPP component password for Jicofo||s3cr37|
|XMPP user for Jicofo client connections||focus|
|XMPP password for Jicofo client connections||passw0rd|
|Enable health checks inside Jicofo, allowing the use of the REST api to check Jicofo's status||false|
|XMPP user for JVB MUC client connections||jvb|
|XMPP password for JVB MUC client connections||passw0rd|
|STUN servers used to discover the server's public IP||stun.l.google.com:19302, stun1.l.google.com:19302, stun2.l.google.com:19302|
|UDP port for media used by Jitsi Videobridge||10000|
|Disable the additional harvester which allows video over TCP (rather than just UDP)||true|
|TCP port for media used by Jitsi Videobridge when the TCP Harvester is enabled||4443|
|TCP port advertised by Jitsi Videobridge||4443|
|MUC name for the JVB pool||jvbbrewery|
|Comma separated list of JVB APIs to enable||none|
|XMPP user for Jigasi MUC client connections||jigasi|
|XMPP password for Jigasi MUC client connections||passw0rd|
|MUC name for the Jigasi pool||jigasibrewery|
|Minimum port for media used by Jigasi||20000|
|Maximum port for media used by Jigasi||20050|
|Enable SDES srtp||1|
|Health-check extension. Jigasi will call it for health check||keepalive|
|Interval of health check in milliseconds||300000|
|Jigasi will record audio when transcriber is on||true|
|Jigasi will send a transcribed text to the chat when transcriber is on||true|
|Jigasi will post an URL to the chat with transcription file||true|
|Handle TLS connections outside of this setup||1|
|Redirect HTTP traffic to HTTPS (necessary for Let's Encrypt)||1|
|Controls which logs are output from prosody and associated modules||info|
Running behind NAT or on a LAN environment
If running in a LAN environment (as well as on the public Internet, via NAT) is a requirement,the
DOCKER_HOST_ADDRESS should be set. This way, the Videobridge will advertise the IP addressof the host running Docker instead of the internal IP address that Docker assigned it, thus making ICEsucceed. If your users are coming in over the Internet (and not over LAN), this will likely be your public IP address. If this is not set up correctly, calls will crash when more than two users join a meeting.
The public IP address is discovered via STUN. STUN servers can be specified with the
Building your images allows you to edit the configuration files of each image individually, providing more customization for your deployment.
The docker images can be built by running the
make command in the main repository folder. If you need to overwrite existing images from the remote source, use
If you are on the unstable branch, build the images with
FORCE_REBUILD=1 JITSI_RELEASE=unstable make.
You are now able to run
docker-compose up as usual.
Running behind a reverse proxy
By default this setup is using WebSocket connections for 2 core components:
- Sinalling (XMPP)
- Bridge channel (colibri)
Due to the hop-by-hop nature of WebSockets the reverse proxy must properly terminate and forward WebSocket connections. There 2 routes require such treatment:
With nginx, these routes can be forwarded using the following config snippet:
https://localhost:8443/ is the url of the web service's ingress.
TODO: Add Apache example.
Disabling WebSocket connections
This is not the recommended setup.
If using WebSockets is not an option, these environment variables can be set to fallback to HTTP polling and WebRTC datachannels:
Follow these steps for a quick Jitsi-Meet installation on a Debian-based GNU/Linux system.The following distributions are supported out-of-the-box:
- Debian 9 (Stretch) or newer
- Ubuntu 18.04 (Bionic Beaver) or newer
Note: Many of the installation steps require
Required packages and repository updates
You will need the following packages:
sudo# only needed if you use sudo
OpenJDK 8 or OpenJDK 11 must be used.
Make sure your system is up-to-date and required packages are installed:
On Ubuntu systems, Jitsi requires dependencies from Ubuntu's
universe package repository. To ensure this is enabled, run this command:
Install Jitsi Meet
Domain of your server and set up DNS
Decide what domain your server will use. For example,
Set a DNS A record for that domain, using:
- your server's public IP address, if it has its own public IP; or
- the public IP address of your router, if your server has a private (RFC1918) IP address (e.g. 192.168.1.2) and connects through your router via Network Address Translation (NAT).
If your computer/server or router has a dynamic IP address (the IP address changes constantly), you can use a dynamic dns-service instead.
Set up the Fully Qualified Domain Name (FQDN) (optional)
If the machine used to host the Jitsi Meet instance has a FQDN (for example
meet.example.org) already set up in DNS, you can set it with the following command:
sudo hostnamectl set-hostname meet.example.org
Then add the same FQDN in the
x.x.x.x is your server's public IP address.
Finally on the same machine test that you can ping the FQDN with:
If all worked as expected, you should see:
Add the Jitsi package repository
This will add the jitsi repository to your package sources to make the Jitsi Meet packages available.
Setup and configure your firewall
The following ports need to be open in your firewall, to allow traffic to the Jitsi Meet server:
- 80 TCP - for SSL certificate verification / renewal with Let's Encrypt
- 443 TCP - for general access to Jitsi Meet
- 10000 UDP - for general network video/audio communications
- 22 TCP - if you access you server using SSH (change the port accordingly if it's not 22)
- 3478 UDP - for quering the stun server (coturn, optional, needs config.js change to enable it)
- 5349 TCP - for fallback network video/audio communications over TCP (when UDP is blocked for example), served by coturn
If you are using
ufw, you can use the following commands:
Check the firewall status with:
For more details on using and hardening SSH access, see the corresponding Debian or Ubuntu documentation.
Forward ports via your router
If you are running Jitsi Meet on a server behind NAT, forward the ports on your router to your server's IP address.
Note: if participants cannot see or hear each other, double check your firewall / NAT rules.
Jitsi Vmware Image
In order to have encrypted communications, you need a TLS certificate.
During installation of Jitsi Meet you can choose between different options:
The recommended option is to choose Generate a new self-signed certificate and create a Lets-Encrypt Certificate later (see below) (this will replace the self-signed certificate).
But if you want to use a different certificate or you want to choose a different challenge type of Let's Encrypt (see below for details), you should create that certificate first and then install jitsi-meet and choose I want to use my own certificate.
You could also use the self-signed certificate but this is not recommended for the following reasons:
Using a self-signed certificate will result in warnings being shown in your users browsers, because they cannot verify your server's identity.
Jitsi Meet mobile apps require a valid certificate signed by a trusted Certificate Authority and will not be able to connect to your server if you choose a self-signed certificate.
Install Jitsi Meet
Note: The installer will check if Nginx or Apache are present (in that order) and configure a virtual host within the web server it finds to serve Jitsi Meet.
If you are already running Nginx on port 443 on the same machine, turnserver configuration will be skipped as it will conflict with your current port 443.
SSL/TLS certificate generation:You will be asked about SSL/TLS certificate generation.See above for details.
Hostname:You will also be asked to enter the hostname of the Jitsi Meet instance. If you have a domain, use the specific domain name, for example:
meet.example.org.Alternatively you can enter the IP address of the machine (if it is static or doesn't change).
This hostname will be used for virtualhost configuration inside Jitsi Meet and also, you and your correspondents will be using it to access the web conferences.
Jitsi Meet server:Note: By default, anyone who has access to your Jitsi Meet server will be able to start a conference: if your server is open to the world, anyone can have a chat with anyone else.If you want to limit the ability to start a conference to registered users, follow the instructions to set up a secure domain.
Conferences/Rooms:The access control for conferences/rooms is managed in the rooms, you can set a password on the webpage of the specific room after creation.See the User Guide for details: https://jitsi.github.io/handbook/docs/user-guide/user-guide-start-a-jitsi-meeting
Generate a Let's Encrypt certificate (optional, recommended)
In order to have encrypted communications, you need a TLS certificate.
The best method is to create a certificate that is signed by a Certificate Authority.This way you can avoid problems with a self-signed certificate (see above for details).The easiest way is to use Let's Encrypt.
Simply run the following in your shell:
Note that this script uses the HTTP-01 challenge type and thus your instance needs to be accessible from the public internet on both ports 80 and 443. If you want to use a different challenge type, don't use this script and instead choose I want to use my own certificate during
If the installation is on a machine behind NAT jitsi-videobridge should configure itself automatically on boot. If three way calls do not work, further configuration of jitsi-videobridge is needed in order for it to be accessible from outside.
Provided that all required ports are routed (forwarded) to the machine that it runs on. By default these ports are (TCP/443 or TCP/4443 and UDP/10000).
The following extra lines need to be added to the file
And comment the existing
See the documentation of ice4jfor details.
Systemd/Limits:Default deployments on systems using systemd will have low default values for maximum processes and open files. If the used bridge will expect higher number of participants the default values need to be adjusted (the default values are good for less than 100 participants).
To update the values edit
/etc/systemd/system.conf and make sure you have the following values if values are smaller, if not do not update.
To check values just run:
To load the values and check them see below for details.
To reload the systemd changes on a running system execute
sudo systemctl daemon-reload and
sudo systemctl restart jitsi-videobridge2.To check the tasks part execute
sudo systemctl status jitsi-videobridge2 and you should see
Tasks: XX (limit: 65000).To check the files and process part execute
cat /proc/`cat /var/run/jitsi-videobridge/jitsi-videobridge.pid`/limits and you should see:
Confirm that your installation is working
Launch a web browser (such as Firefox, Chrome or Safari) and enter the hostname or IP address from the previous step into the address bar.
Jitsi Server Vmware
If you used a self-signed certificate (as opposed to using Let's Encrypt), your web browser will ask you to confirm that you trust the certificate. If you are testing from the iOS or Android app, it will probably fail at this point, if you are using a self-signed certificate.
You should see a web page prompting you to create a new meeting.
Make sure that you can successfully create a meeting and that other participants are able to join the session.
If this all worked, then congratulations! You have an operational Jitsi conference service.
Sometimes the following packages will fail to uninstall properly:
When this happens, just run the uninstall command a second time and it should be ok.
The reason for the failure is that sometimes the uninstall script is faster than the process that stops the daemons. The second run of the uninstall command fixes this, as by then the jigasi or jitsi-videobridge daemons are already stopped.
Web Browser:You can try to use a different web browser. Some versions of some browsers are known to have issues with Jitsi Meet.
WebRTC, Webcam and Microphone:You can also visit https://test.webrtc.org to test your browser's WebRTC support.
Firewall:If participants cannot see or hear each other, double check your firewall / NAT rules.
Nginx/Apache:As we prefer the usage of Nginx as webserver, the installer checks first for the presence of Nginx and then for Apache. In case you desperately need to enforce the usage of apache, try pre-setting the variable
Log files:Take a look at the various log files:
Adding sip-gateway to Jitsi Meet
Jigasi is a server-side application acting as a gateway to Jitsi Meet conferences. It allows regular SIP clients to join meetings and provides transcription capabilities.
During the installation, you will be asked to enter your SIP account and password. This account will be used to invite the other SIP participants.
Reload Jitsi Meet
Launch again a browser with the Jitsi Meet URL and you'll see a telephone icon on the right end of the toolbar. Use it to invite SIP accounts to join the current conference.