Use mediasoup server with plain SDP and ICE


I am looking for a way to use mediasoup as an SFU in an existing WebRTC landscape. So far I have relied on Kurento, but the lack of simulcast has me looking for alternatives.

I looked at the demo and it is completely overkill for my purposes.

  • I have WebRTC client code for browser, native, edge etc.
  • I have my own signaling server that mediates SDP and ICE.
  • I need 1 to N support

Kurento was pretty simple about it, you could put SDP OFFER and ICE candidates in front of them and they would respond with SDP ANSWER and likewise ICE.

I have now found this, which makes me hopeful that there might be something similar with mediasoup as well:

This already seems like a good fit for me. I am missing two things though

  • ICE
  • The ability to elicit an SDP OFFER from mediasoup and consume a corresponding SDP ANSWER.

Re 1) Sorry, I just started using mediasoup today. Possibly my question sounds stupid. I think I read somewhere that mediasoup does “ice-lite” (without knowing exactly how that works). How do STUN and TURN fit in there? Is there really no ICE exchange between the parties?

To 2) I really miss that

I ask for clarification


It’s probably best to slightly adjust your signalling app instead of sending the SDP, we just request connection and send our produced data, server/client will do the rest to sum. (You can see how the SDP is made up after in WebRTC internals)

As for STUN/TURN, silly question you’ll see. Bring your own TURN if you require one. :slight_smile:

"we just request connection and send our produced data, "

I have a vague idea, how that works in a browser. I think you are using the stream provided by getUserMedia(). I have no idea, how that could work if the stream is just available as a GStreamer source…

Through browser the media-soup client will back you apply it as a shim over-top of your project by globally scoping it as a variable you can use throughout.

For sending broadcast through FFMPEG/GSTREAMER that’s another topic but certainly possible here.

For the process of connecting it’s probably best described in few words to not confuse.
1.User makes request for WebRTCTransport.
2.Server creates this transport and sends it back to user the connecting details.
3.User is awaited till till they send their produced media
4.User will send a connect after first produced item.
5. Server will get produced media and connect and reply with connected.

Any SDP work is not required, it’s fairly simple if you can pass the messages along and keep a good queue in situations you need to await a pipetransport connection/etc.

Thanks. Is there any sample code demonstrating that? I’m having a fairly grown WebRTC landscape, based on “good-old” SDP/ICE exchange for various platforms and devices. Looking for a Kurento replacement

and if you scroll to the bottom as well you got more github projects.

It’s tough to suggest anything specific; but to your likings I’m sure you’ll find a few examples worth wild.

I’ve seen many platforms do it like that for years and it’s interesting how media-soup approaches it; I’m quite the fan knowing both.

Can’t say if this will replace it, there’s the obvious learning curve and that could be weeks of wasted time but my opinion would be to run a demo and confirm off that if it’s meeting your performance expectations and more.

I think you’ll be very happy learning media-soup; once versed with the literature tossed around it’s like playing with puzzles.

I’ll mention too that you can run these demo’s for the most part successfully on a single core instance, 500MB ram and a decent network. So don’t go bussing out the big boys for this test it’s relatively linearly scalable depending on how you signal.

1 Like

Thanks. Very helpful