ibc

Yeah please, let the author know your preferred programming language so he'll rewrite the whole software.

Yep, I know. However the effort required to make and maintain DEB/RPM packages for different architectures (mediasoup has a C++ component) is huge.

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 is not an application, is a Node.js library. It's yet nother NPM dependency in your Node.js application. No reason to have a DEB package.

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:

https://mediasoup.org/documentation/v3/mediasoup/rtp-paramet...

If you want to know why we don't use SDP (as communication means between client and server) here a good reading: https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/

Yes, you can use WebRTC DataChannels for sending custom text/binary data on top of a ICE+DTLS connection. BTW mediasoup supports DataChannels.

Any question or comment about mediasoup?

I thought that this news was about mediasoup, not about generic WebRTC questions.

PornHub uses mediasoup for live cams.

It's a Node library, yes.

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.

mediasoup overview here: https://mediasoup.org/documentation/overview/

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:

https://mediasoup.org/documentation/overview/

Of course, this means that you must build your application, including UI, client-server signaling, etc etc.

10 users? the cheapest one.

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.

Majority of RTP media server listen into a separate port for each connection. That's how RTP typically works. This is not TCP connections.

> 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?

Not at all.

You cannot select a specific listening port for a specific transport, because each WebRTC transport requires, at least, a different listening port in the server:

https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtc...

YouIf you want to listen in TLS 443 for all clients, add a TURN server into your backend. Just that.

I thought this news was about mediasoup, not about WebRTC in general. Said that I agree that your scenario is valid without any media server.

We do support TCP ICE candidates for long time:

https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtc...

> TCP candidate so a TURN server isn't needed at all?

This is not true. A router may still block TCP traffic different than TLS or traffic that does not have destinatiuon port 80 or 443. So ICE TCP candidates do not avoid the need for a TURN server in certain cases.

The demo is just a demo. mediasoup is a low level library (no UX into mediasoup). The online demo backend does not have any TURN server. It's obviously recommended to deploy a TURN server.

Just to easily explain that mediasoup is not a replacement for Jitsi or Zoom, but a low level set of libraries for building build different kind of real-time applications, including multi-party videoconference apps (such as Jitsi or Zoom) and others completely different.

mediasoup is a SFU that must be deployed in a reachable server, so STUN is not needed at all. You may need a TURN server if a client has a restrictive firewall that blocks UDP. mediasoup is not a TURN server but you can deploy a TURN server (i.e. coturn) in your backend.

Hi, mediasoup co-author here.

TL'DR': Pornhub uses mediasoup.

I've read many comments here asking about "how mediasoup is different than XXX" or about "mobile apps". I think the Overview in the website should be self explanatory, I'll just paste a fragment here:

https://mediasoup.org/documentation/overview/

--------------------- Design goals of mediasoup and its client side libraries:

- Be a SFU (Selective Forwarding Unit). - Support both WebRTC and plain RTP input and output. - Be a Node.js module in server side. - Be a tiny JavaScript and C++ libraries in client side. - Be minimalist: just handle the media layer. - Be signaling agnostic: do not mandate any signaling protocol. - Be super low level API. - Support all existing WebRTC endpoints. - Enable integration with well known multimedia libraries/tools.

Use cases:

- Group video chat applications. - One-to-many (or few-to-many) broadcasting applications in real-time. - RTP streaming.

mediasoup co-author here.

So you don't know what mediasoup does but you assure that "no need to use a SFU". Too much free time to comment maybe?

e2ee makes sense in one-to-one and N-to-N scenarios. It's just more complex in N-to-N scenarios because you DO need a centralized server so each participant just sends its audio/video once (to the server) and the server distributes it to others given whichever application policy/logic. That's a SFU, and that's what mediasoup does.

mediasoup co-author here.

Comparing Jitsi with mediasoup is like comparing Netflix (backend + apps) with Express.js + libcurl.

Jitsi developers may replace their RTC core internals (including the SFU) with mediasoup + mediasoup-client and you wouldn't even realize of it. Hope this helps.

And somehow this discussion become a general topic about WebRTC scenarios. They do exist, yes, but mediasoup is a SFU scenario. No STUN is required at all. TURN may be needed if the client network/router blocks UDP.

mediasoup co-author here.

> You don't even need servers if you go full p2p

If you have N participants into the same "room", and do not have a central SFU that relays streams to others, then you have a full mesh network with all participants sending audio and video to all the others. Is that the "go full p2p" you meant?. Well, try it, and you'll see how your CPU burns when the browser/app tries to encode your webcam video source N times. And of course, you'd need N x uplink.