Jitsi is described by developers as an “Open-source multiple platform video conference.” Jitsi is a number of open source projects that enable you to build and deploy security solutions for video conferencing easily. Zoom is described on the other side, as ‘Film Meeting, Online Conference, Webinars, Screen Sharing.’. Jitsi Meet is a fully encrypted, 100% open source video conferencing solution that you can use all day, every day, for free — with no account needed. Your recent list is currently empty. Chat with your team and you will find all your recent meetings here.
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.
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 Meetings Descargar
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.
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:
Jitsi Download Windows 10
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.
For us Fellow Jitsters, developing a platform our users can rely on is the most important thing. That means, amongst other things, we are very mindful of the security and privacy aspects that affect our users.
Security and privacy are very broad topics so we are going to try and go through some practical use cases to demonstrate what’s at play.
Fully secure you say… What does this mean exactly?
In many respects Jitsi meetings are simply private by design. To begin with, all meeting rooms are ephemeral: they only exist while the meeting is actually taking place. They get created when the first participant joins and they are destroyed when the last one leaves. If someone joins the same room again, a brand new meeting is created with the same name and there is no connection to any previous meeting that might have been held with the same name.
This is all very important. Some of the systems that let people “pre-create” rooms, have subtle indications that let a potential attacker distinguish reserved from unreserved meetings which then makes the reserved meetings easier to identify and target.
That said, since a name is all that one needs to actually access a room, we have to be really Disk drill file recovery program. careful about how we choose and advertise them. We don’t want others accidentally stumbling into our meetings, just as we want to keep pranksters and snoopers away.
This is generally not much of a problem for small size deployments (remember you can host your own Jitsi Meet) or low profile meetings but it may be a problem if you are using a large and public deployment such as meet.jit.si or if there is significant interest in your meeting.
One has to really keep in mind that the name of a meeting is sensitive and needs to be protected. You shouldn’t send it to anyone you do not want in your meeting. Advertising this name publicly, for example on social media, is something you should only ever do if you truly are comfortable with maximum exposure and the possibility of unwelcome visitors.
Then there’s the matter of choosing the name. If you start a meeting with the name “Test”, “Yoga” or “FamilyMeeting” for example, chances of having some random uninvited people joining are very, very high. How does one pick a good room name then? Our random meeting name generator is a great start. It offers names that are easy to remember and read out loud on a phone call, and come from a set of over a trillion possible combinations. Picking out one of the auto-generated names is therefore quite safe.
If you don’t like the funky way the auto-generated names sound and you don’t want to use a long and uninviting UUID (which you totally could), then go ahead and pick a name by yourself but make sure it is long enough. For example, next time you’d like to have a coffee with someone over video, rather than going for meet.jit.si/coffee, try something with more of a twist.
We are also working on a “bad meeting name detector”. You’ll see a warning if your meeting name has a high chance of collision, so stay tuned!
We also give people the option to set a meeting password. A few important things to keep in mind: if you do set a password, it is your responsibility to communicate it to your peers.
More importantly, keep in mind that your password, just as chat and speaker stats, will be reset once the last person leaves the room. So you have to make sure that you set the password again, if you find yourself ending the meeting and then rejoining.
A similar approach you might consider would be to append a random character sequence at the end of your room name.
Anyone can mute or kick me out of my meeting, what’s up with that?
Jitsi models its meetings after in-person gatherings. Take the case of 10 people having a discussion in a room. You wouldn’t expect one person to have exclusive “kick” and “mute” privileges in an in-person meeting and yet, those meetings usually go fine.
In the vast majority of cases, moderation controls in online meetings serve a different purpose: they help address tech related issues, such as people not realizing their microphones are introducing noise, or people forgetting to leave. Moderation controls help you solve those, so that people can continue their conversation. And now, with that in mind, why wouldn’t you want to enable anyone in the meeting to help solve these kinds of issues?
For that reason our moderation controls are soft, and for everyone.
This is specifically the case on meet.jit.si, since all users are moderators.
If you really, really, really need moderation controls to be limited then consider deploying your own Jitsi Meet instance and configuring it in a way that suits your needs. Once you do, you can configure strong authentication, so only authorised users will be moderators.
We understand the settings in meet.jit.si are not for everyone, so if you’d rather have your own private setup (which we encourage you to do!) you can get started quickly with our Docker setup or the quick-install guide. We’ll be happy to help you in our community.
Does Jitsi support end-to-end encryption?
The short answer is: Yes, we do!
You can turn on end-to-end encryption (e2ee) as long as you are using Jitsi Meet on a browser with support for insertable streams. Currently this means any browser based on Chromium 83 and above, including Microsoft Edge, Google Chrome, Brave and Opera. You may also use our Electron client, which supports it out of the box.
All you need to do is select the “End-to-end Encryption” option in the overflow menu and then make sure that all participants fill in the same pass word or phrase in the Key field.
You can learn more about our e2ee support at: https://jitsi.org/e2ee
Jitsi Meet offers very strong protection even if you don’t explicitly turn on e2ee. Here are more details:
Jitsi meetings in general operate in 2 ways: peer-to-peer (P2P) or via the Jitsi Videobridge (JVB). This is transparent to the user. P2P mode is only used for 1-to-1 meetings. In this case, audio and video are encrypted usingDTLS-SRTP all the way from the sender to the receiver, even if they traverse network components like TURN servers.
In the case of multiparty meetings all audio and video traffic is still encrypted on the network (again, usingDTLS-SRTP). This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge; however they are never stored to any persistent storage and only live in memory while being routed to other participants in the meeting.
It is very important to note that when packets are also end-to-end encrypted, this second layer of encryption is never removed (nor can it be)
Since Jitsi is built on top of WebRTC, a deeper look into itssecurity architecture is very important when evaluating Jitsi’s security aspects.
What do you do with my data?
To begin with, by default Jitsi Meet does not require users to create accounts. Any information they choose to enter, such as their name or email address is purely optional and is only shared with other meeting participants. We do not retain this information after the meeting.
Other pieces of data such as the chat, or speaker stats, for example, are stored for the duration of the meeting and then destroyed when it ends.
Obviously many of these things can be customized by the configuration of the actual deployment that you are using so we are going to talk about the one we maintain: meet.jit.si
Recordings are a bit of an interesting case. They are kept on our servers until we can upload them to the place you indicated (currently Dropbox). If we haven’t managed to do that in 24 hours we still delete them and they are gone forever (so make sure you have enough space in your Dropbox folders 😉 )
Do you use analytics?
Jitsi Meet does not come with any preconfigured analytics engines.
We do use analytics on meet.jit.si, so let’s talk about it.
We are very committed to privacy and security and we are extremely careful about what information reaches the analytics engines we use. That said we also want to provide our users with a great product experience, so we need some visibility into what’s actually going on. We are currently using Amplitude, Datadog and Crashlytics to cover various aspects of the apps and the infrastructure on meet.jit.si. Things that we track in analytics include, an anonymous identifier (you can run in “incognito” mode if this bothers you), bitrate, available bandwidth, SDP offers and answers, product utilization events, mobile app crash dumps (how much various product features are used overall).
Most importantly, once your meeting is over we do not retain any names, e-mail addresses or profile pictures (as we mentioned above, those are only transmitted to the other participants in the meeting).
While we hope that the meet.jit.si configuration will be satisfactory to most users, we completely understand that it will be incompatible with what some others are looking for. If, for any reason, this is the case for you please remember that you could be running your private Jitsi Meet instance in as little 15 minutes!