Due to a internal design optimization in C++, the origin router and target router cannot be in the same worker. In other words, router1.pipeToRouter({ router: router2, etc }) will throw if both router1 and router2 were created in the same mediasoup Worker instance.
I want to make a user be present in multiple rooms, aka routers. But these routers can be anywhere, on the sane worker, on the same host, or different hosts. I was hoping I could pipe them into a new router. Does it mean I won’t be able to do that if their routers happen to be on the same worker? What else can I do in this case?
Thanks for replying. This is a very important use case for me and that’s why I am looking at mediasoup because I did not see this option elsewhere. I want users to be able to freely join other people’s room while also operating their own room. So they will need to be present in two rooms. Because this is a common scenario it’s likely that several such rooms/routers might be present on the same worker. What else can I do to make a user be present in multple rooms/routers?
I strongly discourage the use of pipeToRouter, it doesn’t work in remote cases so it makes most sense for scaling to manually establish the pipetransport.
Also in your case I really don’t think having multiple routers per worker is ideal, load a single router up with multiple rooms and design your signaling server to perform your scaling and command media servers to pass streams to whoever based on IDs/etc. You can setup a room object that holds current users, whos viewing who, who’s broadcasting/etc…
Your application algorithm is up to you, this however is a scaling question and you need to get comfortable first. Don’t tell yourself a router represents a room, a router is not that.
Thanks for your reply. While searching on this topic I came across a lot of valuable information posted by you, so I have to take your suggestion about pipeToRouter seriously.
Again, my goal is let of users broadcast. They are called hosts and they have their own viewers. They can simultaneously join another host’s room and broadcast there to viewers of the second host while continuing to broadcast to their original audience.
And thanks for the insight about rooms/routers and consudering it a scaling problem. This is a very revolutionary idea given that mediasoup exposes all the nuts and bolts. I was deeply influenced by the demo app which has been my only experience with WebRTC, The demo app does a great job of managing rooms. Teh benfit of a room is that it becomes your notification boundary. You are only concerned with the events of this room and it doesn’t matter to you who else is joining other rooms and leaving the rooms. But if I could create my own mechanism of creating a boundary then I could create a different kind if room and I can decide who publishes and views in that room.
What if I just create one router on a worker and put all users in this router? And I can create my own abstraction of a room based on who is watching who. But the server app is doing a lot of work creating tarnsports, producers and consumers, and I don’t understand that deeply. Will I have to mess around with that too? Or can I get away by only adjusting the protoo signalling layer?
Also, what happens in this case if hosts are on two different workers? Can I also handle this by creating my won abstractions? What other things do I need to understand so that i can implement this? Like you can see I have been looking around the code and the forum, asking AI, etc.
Okay so your streamers (hosts) would utilize WebRTC to transmit their stream to the media servers. If the two streamers collaborate you’d connect them via transports for realtime conversation. This event would get recorded, the magic applied and exported in an HLS format for the audience to view. HLS would allow for a large amount of users if these streamers get rather large.
Every user’s connection can become an endpoint to be notified, your APP logic can keep an array/map record of which client belongs in which room and who receives what messages/notifications by such logic.
The whole point is to invent your algorithm, your APP logic will determine routing and who communicates with who, just keep it efficient and scalable for growth don’t shut down because the code forced you to.
The core the worker is assigned to will eventually hit 100% CPU usage which will hinder the experience greatly. It’d be fine for a bit but will be greatly exceeded in no time. You would need to apply scaling logic so the media server(s) can’t get overwhelmed.
That’s where you’re in for a world of hurt, you’re wanting a custom solution like I did. The demo means nothing to you outside understanding how mediasoup works. You will have to get down and dirty with your own signalling methods and ensure they can scale for the userbase you intend on and more for emergencies.
This can often be the situation whether it’s local or remote(separate machines). You want to design an inter-process communication service (I call broker) that keeps records and tabs on everything. It’d ensure Worker #1 @ server 1 can talk to Worker #2 @ server 2 and know both are synced and we can serve it out.
This is not an easy gig, it’s testing… A.I. will just make you depressed.
Thanks again. Live recording for HLS streaming is not going to work if the hosts are going to have a tiktok style live match where milliseconds matter.
I put this question to AI - ChatGPT 4o and O1 and also to Grok3 of twitter. Grok3 had the best answer which I am attaching here. It’s saying to ask the user to broadcast two streams (to two separate rooms) if the users happen to be on the same worker, otherwise pipe them in. I am kinda liking this solution. This might be good enough for a start but what’s concerning to me now is your warning about pipeToRouter. It’s got to do what it says it does otherwise I am in big trouble.
Like I said, both streamers use WebRTC, when they colab they still use WebRTC; the audience itself gets its stream in the format of HLS converted down to media. No compromise there.
That’s a simple solution and works for the most part, it would maybe need to be adjusted.
For small projects it should be just fine but when you scale you should ideally be setting up your pipeTransports manually. It’s your call if it works but something to consider. With manually setting up pipetransports we can connect services locally and remotely.
Be careful with A.I. it’s not going to solve your problems. What you’re seeking to do does take an entire team of programmers and all sorts, it’s not a walk in the park it’s honestly a lot that goes into it.
You can imagine with this discourse or say the demo itself, enough users join it will drop… MediaSoup is simple and sweet, add it to what you’re development you’re the mastermind.
Every users question here is how to scale and it’s not easy, spent years mastering it so good luck!
Thanks for your answers man. You are coming from a lot of background in this area and your insight is invaluable. I at least have clarity on the scale of the problem. That it’s primarily about scaling and I need to get deeper into the weeds.
where milliseconds matter.
