So, is end-to-end encrypted for 1-to-1 meetings or not?

So I know there has been a lot of talk about this, but I still can’t seem to find a reliable answer.

The official /security page of the website states:

Jitsi meetings can 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 using DTLS-SRTP all the way from the sender to the receiver, even if they traverse network components like TURN servers.

“encrypted all the way from the sender to the receiver” seems a bit confusing, because “all the way” could also mean that it goes through something (I feel like “directly” would have been more appropriate), but I’m guessing this means E2E encryption, right?

But then, on this recent thread (2 months ago), a Jitsi dev reacts to a post reminding people that (the public version) is not E2E encrypted:

Yes, that is correct. Currently WebRTC does not provide the necessary tools to make E2EE possible while still being able to use smart video routing techniques such as simulcast and SVC

Also, a Jitsi dev on the main GitHub thread states, in 2018, that:

unless a TURN server is deployed the p2p session will not always succeed and when this happens there isn’t an explicit notification to the user

So, this is all very confusing. A friend of mine is considering using Jitsi for her (1-to-1) telehealth sessions and I can’t tell her for sure that it’s safe, because I’m not convinced at all myself.

I’ll sum up my questions below:

Is E2EE occurring on (the public/maintained version) during one-to-one calls? Is it guaranteed?

Key points being: (as opposed to custom deployed server), one-to-one calls and guaranteed.

Thanks in advance for any help/clarification.


all of this is not relevant to one-on-one communications, it applies only on rooms where participant number > 2

I was not using Jitsi at the time but I believe that p2p indication now exists but it’s really not obvious. when the communication is established: for the host or the other participant, clicking on the own thumbnail (the one at the top right of the screen), then clicking on the indicator appearing at the top left of the thumbnail, then clicking to the ‘show detail’ line will display a line displaying ‘Remote address’: if the remote address value is followed by (p2p) then the connection is point to point. if the remote address appears followed by (turn) on its own, the participants are connected through the server with a turn server (case of for example), if the address is not followed by anything the connection to the remote is direct (port 10000, case of many self hosted servers)
To make things funnier, this indicator does not appear immediately, you have to wait a few seconds that the remote address actually appears (when it’s not yet available, it’s displayed as N/A)

This is an answer on the ‘point-to-point’ question; about the fact the E2E is ‘garanteed’ this is potentially a legal matter and as such an answer on a public forum by an anonymous poster is utterly valueless, I hope that you get this. Only a statement on an official channel by the owner can answer this question.

Thanks for your reply!

OK, I feel like that person should have made the distinction, as he makes it sound like it’s incompatible with WebRTC, period (I’m guessing one-to-one still goes through WebRTC, right)? Anyway, thanks for clarifying.

Alright, good to know. Though in my personal case (or rather my friend’s), that aspect is not critical as long as the video stream is not decryptable by any intermediaries.

One little thing though: your post implies there’s always a Turn server in the middle when using (the public implementation, as opposed to what could be done by installing the server on your own); did I get that part right?

Right, of course. I am not necessarily expecting an official answer here, but possibly elements/evidence that aleady demonstrate that it is the case, either because it was clearly announced somewhere by someone working for Jitsi, or because it was technically proven (somehow).

yes, bur when this was written without the features allowing Jitsi-meet to do video conferencing. implement a turn server but it’s a technical point, it’s the most correct implementation and as such most corporate hosted servers and some personal hosted sites are doing it, but for a personal/small org site one can do without turn server because it’s a bit simpler and not needed if clients are not behind a ‘corporate’ firewall.