Advanced moderation in jitsi

Which is the version of jitsi-meet you use?

ii jitsi-meet 2.0.6433-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.5415-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-turnserver 1.0.5415-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.5415-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.5415-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 2.1-570-gb802be83-1

and for prosody
ii prosody 0.11.10-1~focal1 amd64 Lightweight Jabber/XMPP server

I wonder whether the problem can be some bug from the fact that guests are using a separate domain to connect to … shouldn’t be the case but it is possible.

Can you reproduce the scenario on your setup and collect the following logs:
From moderator and guest js console logs and also execute APP.conference.saveLogs() and add that file. Also collect jicofo logs from that meetings and send all that to me as a private message in the forum or to damencho at jitsi dot org.
Thank you.

Thanks @damencho ! I can produce logs only tomorrow with my collegues as soon as i have the materials i bring you immediately. Thanks again!

@malviven7 Can you test jitsi-meet 2.0.6501, I think that is fixed now?
There was a bug in jicofo. @gpatel-fr you can also give it a try.
Probably we will push that to stable in a few days.

tested it test server Ubuntu 20.04 LTS with Prosody updated to 0.11.10.
Basically works but behaviour is very difficult to understand and bordering on the illogical.

An example of strange case; new meeting, mod disallows everything first (video and mic). In this case (mod alone) the moderator’s video and mic are not cut, while when the guest has already joined it was cut. Not very logical The mod restarts own vid and mic. The guest clicks on video button, is prompted to raise hand, mod see hand, replies. The guest can restart video and mic. So far, so good. But if the moderator cuts again (manually) the guest’s video, the guest can click on own video button and video appears on guest screen, but not on moderator’s screen. At this point if the guest clicks on micro button, the mic is enabled on guest’s side. and the moderator can’t hear it - however at this meeting start, the mod had blocked it ! Having blocked manually the mic and forbidden to restart it, the mic’s button on the guest toolbar should have stayed disabled and another hand raised should have been started.
At this point I am not sure how to enable again guest’s mic. If the mod mutes manually the guest, there is the possibility to invite the guest to raise hand; if the guest replies to this new invite, nothing appears on the moderator’s screen so mic stays muted.
My advice to anyone wanting to use this feature; first ask moderators to train carefully for a specific scenario known to work and hold to it for dear life. Absolutely no improvisation. It’s probably best to forget that it’s possible to cut video. Users can’t see what’s possible or not anyway.
@damencho: Not sure it’s the best idea to push this feature to 8x8 in this state.

I have installed the “unstable” version, tomorrow on morning i try it with my collegues

Hi @damencho and @gpatel-fr , i have tested in deep the unstable release and i can say that my problem is resolved!! I can reactivate smoothly my mic and cam if i am a moderator (icons are white for mod and red for guest) the only thing that in the message appearing to the guest muted is missing who muted him
(fig 1)
unstablefig1
I dont know if it’s correct but after permitting to a guest to activate mic and/or cam moderator is unable to mute him again with the “hard moderation” so guest can reactivate it.
Waiting to a response to my last doubt i can confirm that unstable in my case worked!!
I attach versions of products installed



Thanks!!

Last but not least in the version unstable there is an incorrect translation on the new adjusting feature between quality and performance in this example my broswer is italian but the modal_banner is in english
unstable-quality-performance
and the preferred language in conf is IT

Still the same on 6519. Each time I look at this feature I see a new problem :-). It works when reactivating video the first time, but it works through raising hand. After the ‘handshake’ with the moderator is finished the hand should not be kept raised.
Display in tile mode has changed in 6519 but it’s unrelated (and not unwelcome since the screen real estate is better managed)

Raise hand is removed when you start talking, you see it as still raised after becoming dominant speaker?

There are few more fixes and tests around it that we are currently working on.

I see. When I do my testing, I’m alone before my 2 computers so I tend to use video for moderation since I’m not (yet) in the habit of talking to myself. So when the guest gets video back, said guest could already be dominant speaker (only video was cut, not sound). In this case the moderator should speak, then the guest talk again for the raised hand to disappear. In fact in this case the guest could ask directly to have video enabled (by actually asking for it verbally) however the moderator could not give back video to a specific user without the hand raised dance.
But yes, in a more general case it should not be a real problem.

it’s a complicated feature. Problem it takes so long to make perfect that it has already gotten in stable.

Tested 6530 fresh out the oven, more problems. Not that the original problem I talked about is fixed.

I tried meet.jit.si and it’s useless, I can’t reproduce it here but it’s because it’s too far behind unstable to have the same features.

Will you share what you have found?

The problem with force muting is fixed and the problem with moderator unmuting is also fixed.
If you want to test with the latest version this is alpha.jitsi.net, if you see a debian package it is in alpha.

coming back to this. A bit late but it’s really soul killing to test again and again the same thing. I have done quite of bit of that in my life but I was paid :slight_smile:

So. This is with 6532 on my test server.

Let’s call the 2 incarnations of myself M (moderator) and G (guest)
Moderator connects and creates a room.
Guest connects. We have a meeting. M and G enable the (new and nicer) tile mode.
Moderator displays participants pane and disallows start video. All videos are cut ‘instantly’ (well 1 sec or so) on both workstations.

Moderator allows own video. It’s displayed after 8 seconds on M’s screen and 15 seconds on G’s screen.

G clicks on the video button. Video button is not enabled but a prompt is displayed showing that M has cut video and proposing to raise hand. G clicks on said link.

M sees a prompt saying that G would like to talk, with a link to allow.

Here is the first real problem. This prompt is not staying on screen. If M don’t see or react fast enough (about 5 seconds) this prompt disappears.
If not distracted or busy, M can click this link to allow video for G.

G don’t see anything on screen to acknowledge that video is allowed again. This is the second problem.

G can presume that everything is fine and click video button. Video is enabled back on G screen after 2 seconds but after 15 seconds on M screen. This is not a real problem but it’s friction.

All this was already ‘working’. Now the real test.

M click on the hamburger menu for G in the participant pane and cuts the video explicitly for this participant.
The bad: a box is displayed asking for confirmation adding the useful information that ‘the user can reactivate it at any time’. This is the third problem, G has disabled this very possibility, the message is wrong.
The good: this is not true ! this is fixed, the user has the right effectively removed, G can’t reactivate cam without asking.
Another good point: it works actually : after another ping pong (same limitations as before), the video of G is really visible on M’s screen. Victory.

Total evaluation: it’s markedly better, but far from perfect. And it’s only ONE scenario. There are gazillions of combinations I did not even attempt to test (I have only one soul and some say that’s an exaggeration)

Now. alpha.jitsi.net. I know it’s the same software, but how does it behave ? I use VP9 and alpha is probably with VP8, will it matter ? Some parameters certainly are different

Let’s try it.

When moderator enables back own screen, there is the same delay for M but G gets video back at almost the same time.
When G gets video back, there is no difference in display of video (2 sec)… These differing delays seem to be linked to VP9. Same thing when the video is cut explictly in the participant’s pane by G.
Other than that, everything works the same (for good or not so good) on alpha.jitsi.net and my test server.
I have finally configured it correctly :slight_smile:

After reading this post by @kkd (thanks for sharing your findings !) I have finally understood what’s happening.

Here is the problem’s source: there is a complicated interaction between audio and video moderation and Jitsi devs have made audio moderation a priority (understandable).

So end of game notification is allowed only for audio (and it works perfectly fine).

When moderating only video, there is no notification for the user that it’s possible to ‘unmute’ the video.

I also found few issues today with latest version. moderators can start camera normally. But guest when allowed can start their camera + mic. But video is not seen on other users screens. Audio works fine.
I think something to do with delay of 15 sec , what @gpatel-fr suggested. My guess is this delay may be increasing with number of users online. Will do some more research.

I noted while trying advanced moderation I have lot of warnings like, not sure what it means:

JVB 2021-12-28 09:16:48.315 WARNING: [76] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2936193569] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2936193569 large jump in sequence numbers detected (highest received was 36604, current is 54777, jump of 18172) , not requesting retransmissions
JVB 2021-12-28 09:16:48.326 WARNING: [77] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2185202826] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2185202826 large jump in sequence numbers detected (highest received was 53852, current is 13860, jump of 25543) , not requesting retransmissions
JVB 2021-12-28 09:16:48.326 WARNING: [79] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2185202826] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2185202826 large jump in sequence numbers detected (highest received was 13860, current is 34814, jump of 20953) , not requesting retransmissions
JVB 2021-12-28 09:16:48.330 WARNING: [75] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2185202826] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2185202826 large jump in sequence numbers detected (highest received was 34814, current is 64368, jump of 29553) , not requesting retransmissions
JVB 2021-12-28 09:16:48.332 WARNING: [80] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2185202826] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2185202826 large jump in sequence numbers detected (highest received was 64368, current is 20744, jump of 21911) , not requesting retransmissions
JVB 2021-12-28 09:16:48.336 WARNING: [77] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2185202826] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2185202826 large jump in sequence numbers detected (highest received was 20744, current is 32146, jump of 11401) , not requesting retransmissions
JVB 2021-12-28 09:16:48.340 WARNING: [78] [confId=6d355bd080250fe1 epId=7e97edfa gid=8244 stats_id=Ted-Ved conf_name=fpttrial@conference.meet.myvideoconf.com ssrc=2185202826] RetransmissionRequester$StreamPacketRequester.packetReceived#118: 2185202826 large jump in sequence numbers detected (highest received was 32146, current is 32937, jump of 790) , not requesting retransmissions

Yes that’s was I was having pretty regularly, but with current unstable (6785) I can’t reproduce it, even if (astonishingly) snap Chromium for Ubuntu is still at version 96. I think that there has been some enhancements in JS Jitsi-meet code.