In my case that is true.
That was my initial idea actually. I now clearly see the benefit of not sending ever growing SDP back and forth, but I think such a library will work and solve most use cases just fine. This is basically what I already do anyway, just not as feature-complete as it probably should be.
Now you see why we moved from that painful implementation in mediasoup v1 to pure RTP parameters transmission 
Ok, I can start some kind of separate NPM library to do this. Terribly busy at work so no ETA for now.
Hi guys, @nazar-pc @ea167 @ex3ndr @kwindla.
Just the README with provisional API usage is done, but let me know your opinion about it (about the exposed API):
Makes sense to me.
I have a question about .consume() method though: is it needed there?
There is transport.observer.on(“newconsumer”, fn(consumer)) and receive endpoint can just subscribe to that and then fire negotiationneeded as the result of it without exposing additional API methods.
No, we cannot assume that the remote endpoint must consume everything that is produced in the Router. What to consume is up to the application, not up to mediasoup or mediasoup-sdp-bridge.
I’m talking about consumers created on transport, not router, the same one you specify in receive endpoint as an argument.
Ah ok, I understand. It makes sense.
However, when using mediasoup-sdp-bridge, associated Producers are not created by calling transport.produce() but by calling sdpSendEndpoint.receiveOffer(sdp). So, to be symmetrical, I think it’s better to have a explicit method in sdpRecvEndpoint to consume.
Well, that can also be avoided because you can always use transport.observer.on(“newproducer”, fn(producer)) to get those producers. Not sure if that is more ergonomic though.
Who did create those Producers? Remember that the server just received a SDP offer.
Maybe are there some missing directories from github repository?
There is nothing in the repo yeet (but the README) 
The idea is to discuss the API before implementing it.
Ahh ok 
In my case, I would use the proposed API to configure the GstWebrtc plugin, that needs plain SDP. For now I “manually” convert the textual SDP from/to JSON representation used by mediasoup. It is far for optimal.
Yeah, that’s the purpose.