"1 to multiple sessions" topology

OpenVidu v2 How to implement?
1

I’m planning a streaming platform which will host many small sessions (target is 160 sessions at the same time) where each session will be limited to few participants, up to 4-6 peers on each session. There will be then a single publisher common to all the sessions: the 7th peer acting as a “broadcast” host - therefore the topology may be not so obvious being a mixture of 1:1 and 1:N. I need some advice about how to deal with that topology before to start deployment phase:

  • would the 7th “broadcast” peer need to join all the session publishing the same stream - which would dramatically affect the upload bandwidth need - or do the MCU/SFU manage that by routing the same stream to all the peers?
  • would be better adopt OV Enterprise Beta in order to switch to mediasoup - if mediasoup better handles routing? of course going Beta instead of Pro means dropping video filters and exposing the platform to the risk of major bugs.

Thanks
Stefano

2

Hello @Stefano,

OpenVidu session topology is not designed to have one participant publishing to all sessions at the same time. You you have to find some way to achieve this in the most efficient way.

There are several possibilities:

  • Several independent sessions: It is easy to implement, but the “big publisher” should join and publish in every session. Too much upload bandwidth.
  • Create a big session with all participants: And the you can “virtually” divide some participants into virtual sessions. But you can not reuse any sample code because it assumes all participants in the same session belongs to that session. Also, all participants will receive all the notifications from all other participants from other virtual sessions. Maybe too much notification overload.
  • Several independent sessions with “virtual multiplexed publisher”: You can create multiple sessions with 4/6 participants on it. Also, you can create a session with the broadcaster-publisher participant. And then, connect in the server side the broadcaster session with the rest of the sessions. How to connect two sessions in OpenVidu? The feature is not available in the API, you should cheat OpenVidu to do it. The idea is to simulate a participant in a real browser but executed in the server. So this fake participant can subscribe to the broadcaster in their sessions and simulate another fake participant as a publisher in the rest of the sessions. How? One strategy is executing openvidu-browser SDK in Node.js and using Kurento as a WebRTC stack. In that way, you can later manipulate Kurento MediaPipeline as you wish to get media from broadcaster and send it to the rest of the sessions. It is not easy, but you can get inspired from the browser-emulator we have implemented to load test OpenVidu. As the name suggest, it is a browser-emulator that executes openvidu-browser SDK in a Node process using Kurento under the hood: openvidu-loadtest/browser-emulator at master · OpenVidu/openvidu-loadtest · GitHub

You can use OpenVidu PRO or OpenVidu Enterprise. Both versions will work, but with OpenVidu Enterprise you will have more users per CPU. Also, take into account that OpenVidu Enterprise is still in beta, so some things can go wrong.

Best regards

3

Thank you for the answer @micael.gallego and for the precious advices.

I looked into the dockerized chromium simulator repo you’ve linked and I think that the third option you suggest it’s smart and feasible.
I would just add that there may be another option similar to the second one you proposed, which may be faster to deploy since it’s almost client-side only: I’ve already deployed some months ago an OV stack with multiple sessions running on the same client to deal with a similar but more complex scenario (a sort of virtual meetings corporate hub): it has been a bit hacky but we eventually managed to get the desired results. That said, the second option you’ve suggested may be slightly changed to a client-side solution made of

  • a ”big session” used just to allow all participants to subscribe to the same publisher
  • a “small session” with 4/6 participants
    Of course the server would have to manage the notifications as usual, but since the “big session” is running with just a single stream subscribed by all the participants, without any other interaction, I guess that the notifications would peak just during the subscribers connecting/disconnecting to the “big session”, not affecting the overall performance continuously I mean. Else, I’m wrong and the Kurento server isn’t structured to deal with such “cross-notification” volume – but take into account that I’ve already planned to deploy the stack on high CPU stuff such as those new EC2 AMD Epyc instances because there may be video filters to apply too – that’s why I was looking to stay on the Pro plan instead of Enterprise to get the MCU features.

Thanks
Stefano

4

Yep… your last proposal seems the be the best one in terms of bandwidth usage in for the broadcaster and ease of implementation.

From the notifications point of view, the “big session” will receive less notifications as only the broadcaster will be publishing on it.

Good catch.

5

Ok let’s go with that then and see if it works:)

Thanks
Stefano