I tested my Jitsi installation with channelLastN: 1 with a some collegues (between 20-30) and for like 30 minutes the bandwidth usage was as expected, Tx: 45~60 Mbps/Rx: 20~25 Mbps with 23~25 participants, most of them sending video.
Thanks for the answer, @Neil_Brown. Why would Firefox not having Simulcast cause an increase of Tx traffic in the server? As far as I understand (which is very little) simulcast is used by the browser for sending different bitrate streams to Jitsi, which would mean that if you don’t have simulcast you actually would send a stream with even lower biterate, which would mean a lower Rx BW usage in the server.
Can you please elaborate a little bit on why do you think that could be the reason?
Also, so the solution would be to ban browsers that do not support simulcast?
Firefox will use more TX bandwidth because, since it sends only a single layer, instead of forwarding a thumbnail stream out to users we have no choice but to send out Firefox’s only stream, which would be 720p (as opposed to what we’d normally use: 180p).
@bbaldino Thanks for your input. I thought that with channelLastN: 1 all participants would the stream of only the person that is speaking, am I right?
If that is the case, even though the Firefox users have their cameras turned on, if they are not the active speakers (and nobody pinned them), their video streams should not be received by any users. Is this correct?
Yeah, that’s right–sorry I didn’t notice you said that you had configured the bridge in that way. In that case I don’t know what would be responsible for the bw spikes, but could be all sorts of reasons. If you’ve got datadog or something set up it might give some clues.
The great jitsi dev team are working hard on Firefox/Safari. In the below issue and also the last Community Call it was mentioned we could be 2-3 weeks away from having it all sorted - on iOS too I believe!