Participants joining a call get assigned a different / wrong encryption key?

I work as part of a virtual team We start every day with a short audio call (ie we turn of the video). I have convinced our organisation to use Jitsi for this call. We use e2ee.

For over a month now, every morning we have the same problem:

At least once when a person joins the call, the sound get garbled for everyone. I assume that means that they get a different encryption key? That person can sign out and sign in again many times, but the problem will remain each time to join the call.

The only solution that works is that everyone else leaves the call and re-join; then everything works fine.

Sometimes the problem re-occurs a second time when someone else joins the call (not necessarily the next person to join the call, everything may work fine for the next few people to join and then it re-occurs when someone joins). Sometimes the problem does not re-occur a second time.

It is extremely rare for the problem not to occur at all.

Any idea what causes this? And even more importantly: what, if anything, can we do to prevent this from happening?

Thanks

It seems to re-key every time any participant joins or leaves now. That always disrupts the conference, and sometimes it goes wrong and doesn’t recover.

Thanks for the feedback, looks like a bug indeed. When a new participant joins we ratchet the key so it changes, but without the need to signal such a change.

Can you please open a GH issue?

Thanks.

I have opened an issue at Github.

I cannot find it, can you link it please?

I think you found it, as you posted a response.

I am not sure whether that response was to me though? As we are not self-hosting, but using meet.jit.si, I do not think we can make the change you suggest.

Thanks!

You can, with an URL override: https://meet.jit.si/saswswsws#config.videoQuality.preferredCodec="VP8"

I’ll be watching here and on the GitHub issue as discord keeps changing the override url to https://meet.jit.si/saswswsws#config.videoQuality.preferredCodec="VP8 (removing the last quotation mark from said url) and thus the override doesn’t really apply there

OK, thanks.

We will try this in tomorrow’s call.

(just FYI, next week we have our annual face-to-face staff meetings, so after tomorrow, there will be no Jitsi calls for a week)

OK, we have been overriding the preferred codec as per your suggesting last week, by using a link like:

The problem does not occur as often now as it did before, but there are days that the problem still occurs, so it does not solve the problem.

We just fixed a couple of issues around that. They will be part of the next release.

I’ll check the release notes when the next release comes out. Also wondering if the overrides in the urls are reflected in url shorteners, so I could workaround the problem I had when sharing the url in discord.

<< We just fixed a couple of issues around that. They will be part of the next release. >>

Thanks. I assume you are talking about the code server side (not the Jitsi Meet app)?

Does that mean we should stop using the override code in the url?

This morning all 9 participants could join the call and they did not get encryption noises, but 6 out of the 9 did not hear anything at all (while the other 3 were definitely talking), and they claimed they could not unmute themselves.

They could see all the participants in the call, and they could send messages in the chat (so they were connected to the right call, the audio just did not work).

Could that be because we still add the #config.videoQuality.preferredCodec=“VP8” to the URL, while we should no longer do so?

Thanks

The changes are on the web app. You can test them if you are using the unstable builds, or by using beta.meet.jit.si.

That sounds (no pun intended) unrelated. Do you have any JS logs for those?

You should still do that, we haven’t added VP9 support.

<< That sounds (no pun intended) unrelated. Do you have any JS logs for those? >>

No, sorry. I would not know how to access those (we use a chromium browser to join the call; I think most use Chrome, I use Brave).

If you can, try to ask users to get their JS console logs, in case something goes wrong.

Is it safe to assume that E2EE for VP9 will be available sometime in the not too distant future?

Yep.