tickets #155185
open
meet-o-o disconnect/mute with three attendees
Added by lkocman 3 months ago.
Updated about 2 months ago.
Description
Hello team,
I was trying to find an open tracker but couldn't find one, so here we go.
We've decided to use a temporary alternative (SUSE's google meet) insetad meet-o-o as the last two meetings (Thursday weekly meeting, and Releng meeting on Wednesday) were super unstable.
https://etherpad.opensuse.org/p/ReleaseEngineering-20240207
Adrian mentioned that it's caused by misconfirugration of jitsi and it happens mostly when a third person connects (one gets muted, the other gets disconnected).
Another issue was that I have been stuck for 10+seconds several times during Thursday. So the communication was cumbersome.
I'd like to make sure that jitsi is fully usable before we switch back.
Meeting invitation was already updated with the new google meet link
https://calendar.opensuse.org/teams/release/events/opensuse_release_engineering_meeting
- Category set to Jitsi/ Meet
- Private changed from Yes to No
- Tracker changed from communication to tickets
- Assignee set to SchoolGuy
- Priority changed from High to Normal
It's a "test" instance for a reason ...
- Description updated (diff)
IIRC, a call with two people uses P2P transmission, but when you have 3+ participants, things get rerouted over the server instance so that each participant's bandwidth does not skyrocket (as it would when continuing to do P2P). Audio getting muted would suggest that one of the new IP-level connections isn't working. Possibly firewall related?
We'll be back using jitsi beginning by next weekend. Somehow the situation improved recently.
lkocman wrote in #note-5:
We'll be back using jitsi beginning by next weekend. Somehow the situation improved recently.
So from my side as an admin, I can give the following two cents:
- The issue is not reproducible from my side. I just tested it again and it worked for me.
- It appears to be a timeout-related issue. I cannot tell if this is due to a local configuration issue or a firewall-related issue.
- The issue can be fixed by restarting the Jitsi videobridge. -
systemctl restart jitsi-videobridge
Since SUSE IT doesn't provide solutions for application monitoring according to my inquiry a few weeks ago I have no way to setup an automation that notifies me of this event happening or even gathering statistics of the outages for status.opensuse.org.
Since after a restart of the bridge, the service is operational again I really believe that the configuration of the Jitsi instance is working as intended. I will open a ticket right now with SUSE IT to setup permanent network monitoring for this server.
It should be noted that it "feels" like it is working most of the time, mostly because I am usually quite quick to respond with a jitsi-videobridge restart when /bar people (who use the service most actively) ping about it being broken.
Monitoring sounds good, but I do not think it is normal for the service to require a restart that often to resume operation?
We've had complains again today. Richard required multiple reconnects etc, but that's partially also because of his complex audio setup.
Also available in: Atom
PDF