Our goal is to bridge a dozen or so JVB servers together with octo in a hub architecture, and hopefully scale to 1000 participants or more in a single room. For our application, we’re willing to do LastN=9, which prevents the exponential explosion. And we’re willing to compress to 1.5mbps video to reduce the number of bits flying around.
Our theory is to have one JVB that has no actual participants on it, just octo connections. That’s the “hub”. Each JVB connected to that hub would have 100 or more participants.
Any thoughts on this approach?
In our tests, a small bare metal server (4 core / 8 thread) on Packet.com, JVB will support ~120 participants, and with a supper-massive bare metal machine (26 cores / 52 threads) JVB will do ~150.
With the big machine, we have CPU, Memory and Bandwidth to spare… so I’m guessing the limit is something in the software, OR we’re doing something wrong and still exploding exponentially, in that amount of bandwidth.
Grateful for any and all feedback and suggestions!
As far as I know, Jitsi can’t handle that kind of volume. (Maybe if this is completely on an internal private network that has gigabit to each user…)
Instead: Share the video to a private YouTube stream. Have people watch the video via YouTube. (With 1000 people, I seriously doubt that all will be presenting.) Reserve the Jitsi channel only for presenters.
We need to keep the branding in-house and latency is a concern (so chat participation by all makes sense)
WebRTC streaming might work, however… Is there an opensource webrtc streaming project somewhere than can injest RTMP from jibri? (Antmedia’s opensource version doesn’t support webrtc streaming)
We wanted to support something like this initially (that’s what the R bit in the octo packet was there for), but it evolved in a different direction. Currently the bridge does not forward packets coming from one bridge to another (i.e. the code assumes he architecture is a full mesh), so you’ll need a modified version for the hub.
Another thing to have in mind is that currently LastN is not applied to the octo link. The intention is to support it eventually, but for the time being you can do the limit on the client.
Also note that with 1000 participants you will probably run into signaling limitations (amount of signaling traffic, number of advertised remote streams).