I think recent changes to Jitsi-videobridge introduced a small bug.
Constructor of RTPChannel performs this call even before the XML attributes of the channel are parsed:
java
if (RTPLevelRelayType.MIXER.equals(getRTPLevelRelayType()))
As a result, getRTPLevelRelayType sets the type to a default, which is a "translator". When attributes of the channel's XML description are parsed later and the attribute `rtp-level-relay-type="mixer"` is discovered later in Videobridge.handleColibriConferenceIQ, the code tries to set the type to "mixer". But it does not work, because the logic in RtpChannel.setRTPLevelRelayType allows to set a type only if it is not set set or it is the same. Since each RTPChannel has now "translator" as an initially set type, it is impossible to set "mixer" at all, as far as I understand.
This seems to be a regression from previous versions of the video bridge. I guess it should be still possible to set a "mixer" mode during conference establishment.
···
---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/9