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?
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
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?