How is the sender limiting feature supposed to work?

Hello

I would like to update the translation for the feature landed yesterday, and I want to see how it works to try to give the best translation. I have a hard time of it though.

I have setup in jicofo.conf:
conference: {
max-audio-senders = 2
}
So I create a room and ask to start with audio muted.
I then connect to the room on another computer and everything is going to plan, that is, the user is seeing sound disabled.
The non moderator then proceeds to enable sound. It succeeds. Great, it’s expected yeah ? However what Jicofo says:

Jicofo 2021-12-01 14:42:02.766 WARNING: [19] [room=gazobu2459@conference.xxxx.xxx.xxx meeting_id=ba518503-5341-4b26-9c67-5110fc04b97b] JitsiMeetConferenceImpl.onAddSource#1541: be12c96a: Source add rejected. Maximum number of audio senders reached.

Now that’s not what one expects from the word ‘maximum’. When one speaks about capacity, the maximum is usually meant as the maximum allowed. If you buy a car having officially 5 seats, you are not expecting to get fined if you take 4 persons with you.

However, whatever the jicofo log is saying, it has not blocked the user to enable the button (at least apparently). But the sound don’t come through to the moderator so Jicofo has not lied.
And indeed the browser console log says:

Logger.js:154 2021-12-01T13:42:02.839Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>:  UnhandledError: Jingle error: {"reason":"resource-constraint","msg":"Source add rejected. Maximum number of audio senders reached.","session":"JingleSessionPC[session=JVB,initiator=false,sid=rq7fv7a7kfn8]"} Script: null Line: null Column: null StackTrace:  Error: Jingle error: {"reason":"resource-constraint","msg":"Source add rejected. Maximum number of audio senders reached.","session":"JingleSessionPC[session=JVB,initiator=false,sid=rq7fv7a7kfn8]"}
    at https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:462829
    at I.Handler.handler (https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:180542)
    at I.Handler.run (https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:175841)
    at https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:184279
    at Object.forEachChild (https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:167509)
    at I.Connection._dataRecv (https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:184128)
    at M.Bosh._onRequestStateChange (https://meeting.xxxx.xxx/libs/lib-jitsi-meet.min.js?v=5622:2:204112)
r @ Logger.js:154

Is this expected ?

Edit: I forgot to say that there is no notification.

max-audio-senders and max-video-senders is a mechanism to limit the number of unmuted users at a given time in the call. In large calls, when a lot of users unmute their camera/mic at the same time, that can create a signaling storm and can overload the prosody and result in a broken system.
The assumption is that these thresholds will always be greater than startWithAudioMuted/startWithVideoMuted limits.
This will work for any values > 3 since 3 is the threshold for the media in the call to switch over to the jvb media connection.

Thanks, that explain the motivation behind this feature.
However I don’t see why in the messages that are supposed to be displayed to the user there is the word ‘temporary’ (‘has been temporarily blocked’), while I don’t see in Jicofo source code where this limit could be raised ? If it’s necessary to restart Jicofo to raise the limit, how can this be effective at allowing video back when the storm has subsided ?

The reason why we have “temporary” in the notification is that the camera/mic icon gets enabled again when the number of unmuted users in the call drops below the threshold set in the Jicofo config. This can happen because of user action. Currently it has been implemented as a hard limit in Jicofo and it doesn’t dynamically adapt to the load experienced by the system. We believe this is temporary and wouldn’t be needed when our system can manage load fluctuations in a better way.