First of all, I’d like to mention that I have read documentation, understand rationale behind current design and respect its decisions.
Mediasoup looks great in terms of low level access it provides, that is a very useful and flexible.
However, while it is often mentioned that being agnostic to signaling is a big advantage, de-facto requiring a custom client is an equally huge disadvantage. It basically makes a trivial thing of connecting anything that speaks WebRTC into long, non-trivial and IMO unnecessary complex journey.
Requiring custom data structure that needs custom implementation for parsing and generating SDP for every single platform basically defeats the purpose of being signaling agnostic (IMHO) and is not a requirement that facilitates adoption.
I’m coming from GStreamer side, but unlike many others, from webrtcbin, its WebRTC implementation, similarly to @vpalmisano in Using GStreamer webrtcbin as MediaSoup client
However, I’m using a different language (Rust) and essentially have to re-implement all of the work done by others a few times already.
This is counter-productive for many reasons and from my quick search I don’t seem to be the only one so frustrated.
What do mediasoup developers think about
toSdp utility functions on mediasoup server?
De-facto standard to use with WebRTC today is SDP with Unified plan.
Just parse and generate Unified plan SDP, no need to change mediasoup internals.
Was this considered before as an option?
I suspect mediasoup-client has a lot of this done already, at least for SDP generation.
This would be a huge win in terms of interoperability with GStreamer, plain libwebrtc, Pion and many other implementations and bindings in various languages. It will also not force people to use mediasoup-client unless they need something other than the only way to connect to mediasoup server.