Bandwith calculation between Client and JVB fail

[gjaekel]

Said that Video is disabled on joining the conference, a few moment after a Video stream (Cam or Screenshare) is started the first time the own connection indicator drops becomes gray and the Connection Quality value in the corresponding popup vanishes. At the client of all other members, the Connection Indicator for the participant drops to "red" and Quality is "bad".

This unfortunately isn't just a cosmetic bug: The RX/TX connection bandwith between the the participants client and the JVB isn't updated anymore and is treated much to low in the most cases. This will lead to the fact, that video quality is very low or the bridge even disables further video transmission ("bandwith to low").

[gjaekel]

The issue is caused by a bug while parsing the legacy syntax version of a certain section in the the downloaded webclient configuration (config.js). The change/bug is present at least since the V1.7.1 of the Pàdé-Plugin (introduces with the upstream Jitsi components used here, espc. the WebClient).

The core issue is filed at jitsi/docker-jitsi-meet#1318, together with a workaround and the analysis.

By applying the workaround at the end of the config_custom.js of our plugin here as a POC, I also was able to get rid all of of the described problems. But of course, the issue should be fixed by updating the generator for the config.js to adopt the new config syntax.

For the POC, I added the lines

// 20230130/gj   https://github.com/jitsi/docker-jitsi-meet/issues/1318
console.log("config.videoQuality.maxBitratesVideo is", config.videoQuality.maxBitratesVideo);
config.videoQuality.maxBitratesVideo = null

at the end of the config_custom.js. As expected, the console logs the object with the legacy stanza. This fixed the issue for V1.7.1 as well as for the "withdrawn" V1.7.4.

BTW: Setting it to null seems to result into a "slow start" of estimated bandwith: Within some seconds after starting the Video stream, the connection quality is rising step by step ("red" - "orange" - "green"). So maybe configuring null may become an additional (experimental) optional UI config option named "self-aligning".

[gjaekel]

ToDo: Update the ConfigServlet (https://github.com/igniterealtime/openfire-pade-plugin/blob/main/src/java/org/jivesoftware/openfire/plugin/ofmeet/ConfigServlet.java) to meet the new syntax and semantics of VideoQuality.