I think @alpaylan needs to specify a little more what their goal/idea is, but from a very narrow perspective this seems implementable. What I’m envisioning is actually running mediasoup server on the client side, and having that communicate with the main server via pipeTransport. The client-side server would be capable of forwarding raw RTP to other clients as long as they’re able to connect to it via ICE LITE, but this is obviously NOT guaranteed unless you have some kind of control over what kind of network the forwarding client exists on.
@nazar-pc mentions a very important point about scalability. WebRTC mesh networking is basically not scalable at all, and peer to peer connections only work like 80% of the time. The rest of the time you need to rely on TURN to forward data between peers over a central server… in which case you’re no better off than you were just using an SFU (mediasoup).
An additional warning for @alpaylan … be careful about trying to implement forwarding in WebRTC (mediasoup developers have ALREADY done the work for you here). I initially tried to build my own SFU using node-webrtc, and found out after like 50 hours of labor that there was no way to forward/pass through an incoming stream to an outgoing connection without first decoding and then encoding it again (not with node-turn or any Chromium based solution that I’m aware of). Massive CPU usage.
Learn from my pain!