DataChannels are transmitted over the same UDP/ICE "connection" that is used to transmit audio and video packets. So if you plan to send real-time data (for example: real-time subtitles, metadata related to the current video position, etc) by sending such a data over DataChannel it will reach the remote without delay over the audio/video. If you use WebSocket to transmit the data, there may desynchronization between audio/video and data because they use a different network path.
mediasoup (server side, so the Node + C++ component you mean) does not implement "RTCPeerConnection". That's just needed for browsers. In mediasoup we don't use SDP but specific RTP parameters as defined here:
mediasoup (in server side) is a Node.js library or a NPM dependency that you integrate into your Node.js app. Of course it comes with tons of C++ lines but, from the point of view of the user, it's just yet another NPM dependency into your Node.js project.
Yep, two active developers but being just a set of libraries it's good enough. We also get nice contributions (C++ fixes and optimizations) via PR in GitHub. And we use mediasoup in different commercial products.
Jitsi is a full application (web app, backend servers) with a specific use case: meetings (similar to Zoom or Google Meet).
mediasouop is not an application but a set of server and client low level libraries to build whichever kind of audio/video applications (not just meetings). You don't "install mediasoup and configure it". You create your Node app and integrate mediasoup as you do with any other NPM dependency. Same in client side. More here:
In WebRTC spec (although not super mandatory but the current way to go), the client no longer signals its sending SSRCs into the SDP but a MID and optional RID values (if simulcast is in use), and those MID and RID are not supposed to be unique across all participants (not at all, but neither SSRCs are supposed to). Those MID and RID values are signaled in the SDP and then included into RTP packets as header extensions. The remote matches RTP packets based on them and then learns the associated SSRC for a faster lookup for future packets.
Anyway, WebRTC is not just about RTP. In fact, before RTP happens, ICE and DTLS must de done.
This is RTP not WebSocket or HTTP. Media servers need a separate port for each RTP communication. A hack could be done to make all WebRTC endpoints to use a single port in mediasoup side. However mediasoup also support plain RTP endpoints and, in those, you need to be ready to listen for RTP from any remote IP:port (you don't know it in advance due to NATs). In WebRTC we can use ICE user/pwd (previously given to the server via signaling) but that's not possible with plain/regular RTP (no ICE).
Why is that so important? As I said, choosing a specific port is not enough. This is not TLS. An aggressive firewall may drop those TCP connections because there is no TLS data on them.
> is like sending information at several resolutions and each peer selecting the best one.
Well, no. This is not about sending all video layers to all receivers and let them choose which one to render. Not al all.
The purpose of video simulcast/SVC is the opposite: make the SFU decide (based on estimated per receiver bandwidth or whatever) which video layers to deliver to each receiver, so a HQ video of 8 mbps does not break your Internet downlink (you just receive the lowest video layer which is 1 mbps, for example).
And more important: no, the server can not send the same UDP datagram (the same RTP packet) to all receivers. The server needs a different RTP sequence number count and a different SRTP encryption keys with each receiver.
I'm afraid this is not so easy as you say, not at all.
BTW: Do you want to say something about mediasoup? or just about your stuff?
And you are wrong. RTP video cannot be sent that way because each receiver must also send back feedback to the sender. RTP protocol is more complex than just sending UDP packets everywhere.