I ask not to be immediately stoned or accused of blasphemy.
I had already detailed my use-case in another thread.
With respect to the mediaserver, I’ve been relying on Kurento so far. This part I could substitute with Mediasoup.
But my use case is “unfortunately” that 95% of the connections are P2P connections. I currently handle this with my own JS client and signaling server. But I miss SVC and Simulcast and also all the possibilities of iteratively adding and deselecting media streams.
I have now tried something with PeerJS on the fly. It also worked, but they don’t have the “iterative” feature either. And the project seems dead, bugs are not fixed for a long time.
Now my question: If I now already have mediasoup-client in my app, is there any way to benefit only from the “client-side” capabilities of mediasoup, i.e. to get to SDP and ICE via some “hook”? The distribution is then again up to my socket protocol. Of course, this is just half the truth, the other way around would also have to work (feeding ICE and SDP from a remote mediasoup-client).
But I guess this is impossible. Unfortunately, I see the “holy grail” in traces too often not to at least ask…
When one WebRTC client is sending track to another, it calls setLocalDescription, signals an offer to another client, receives an answer and calls setRemoteDescription. But the approach in mediasoup-client is different. It calls setLocalDescription, parses SDP, creates an answer itself and immediately calls setRemoteDescription - all in the same function. Only then it emits ‘produce’ event for the application, and not with SDP, but with the data specific to mediasoup. There is just nothing to intercept. All is built on the assumption that there is a mediasoup server on the other end.
