Mediasoup – WebRTC Video Conferencing • Hacker News Board

Re: Mediasoup – WebRTC Video Conferencing

#41

Post by orixilus » Fri, Apr 03, 2020, 11:30 AM UTC

ibc wrote: post #38

pkstn wrote: post #36

Does it do TURN/STUN?

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.

I just tried the demo - btw, best UX so far from all that I've tried.

It works fine on the same wifi network, but won't connect if one of the devices is using 4G network - is this because the TURN server is not setup? Is it easy to implement that?

Re: Mediasoup – WebRTC Video Conferencing

#42

Post by supermatt » Fri, Apr 03, 2020, 11:52 AM UTC

ibc wrote: post #38

pkstn wrote: post #36

Does it do TURN/STUN?

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.

Are there plans to support a TCP candidate so a TURN server isn't needed at all? It feels a bit wasteful to effectively use a TURN server as a TCP->UDP proxy for a publicly accessible server.

Re: Mediasoup – WebRTC Video Conferencing

#43

Post by ibc » Fri, Apr 03, 2020, 12:10 PM UTC

bryanrasmussen wrote: post #39

ibc wrote: post #37

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…

I read the whole thing. I am really confused as to why out of that you chose "Pornhub uses mediasoup" as the TLDR?

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.

Re: Mediasoup – WebRTC Video Conferencing

#44

Post by ibc » Fri, Apr 03, 2020, 12:11 PM UTC

orixilus wrote: post #41

ibc wrote: post #38

Earlier quoted context omitted.

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.

I just tried the demo - btw, best UX so far from all that I've tried. It works fine on the same wifi network, but won't connect if one of the devices is using 4G network - is this because the TURN server is not setup? Is it easy to implement that?

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.

Re: Mediasoup – WebRTC Video Conferencing

#45

Post by ibc » Fri, Apr 03, 2020, 12:14 PM UTC

supermatt wrote: post #42

ibc wrote: post #38

Earlier quoted context omitted.

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.

Are there plans to support a TCP candidate so a TURN server isn't needed at all? It feels a bit wasteful to effectively use a TURN server as a TCP->UDP proxy for a publicly accessible 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.

Re: Mediasoup – WebRTC Video Conferencing

#46

Post by ibc » Fri, Apr 03, 2020, 12:20 PM UTC

fulafel wrote: post #33

ibc wrote: post #32

Earlier quoted context omitted.

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 po…

We may be talking past each other, I'm talking about webrtc in general as the subthread was discussinh that. Think about a limited user count screen sharing or vr app with a/v comms built in for example.

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.

Re: Mediasoup – WebRTC Video Conferencing

#47

Post by ibc » Fri, Apr 03, 2020, 12:21 PM UTC

manthideaal wrote: post #35

To understand the terms: webrtc, stun, turn, mesh, sfu, mcu, ice and trickle ice, there is (1). 15 minutes to understand what is all this about. What about IPv6 stun and turn?, it seems other people asked the same idea I thought: (2) bout all of this, one is the answer is: As IPv6 takes over the complexity of new networks, STUN and ICE will become irrelevant. I think that with the surge in video conferences and rtc,…

Thanks for the SPAM. Let's talk about whatever you wish to say.

Re: Mediasoup – WebRTC Video Conferencing

#48

Post by supermatt » Fri, Apr 03, 2020, 12:39 PM UTC

ibc wrote: post #45

supermatt wrote: post #42

Earlier quoted context omitted.

Are there plans to support a TCP candidate so a TURN server isn't needed at all? It feels a bit wasteful to effectively use a TURN server as a TCP->UDP proxy for a publicly accessible 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.

Maybe I could allocate a port to use for an additional low priority tcp candidate via configuration, or would I need to dive into the code for this?

For example, I could supply the generated udp and tcp candidates in addition to a tcp:443?

What are your thoughts?

Re: Mediasoup – WebRTC Video Conferencing

#49

Post by ibc » Fri, Apr 03, 2020, 12:49 PM UTC

supermatt wrote: post #48

ibc wrote: post #45

Earlier quoted context omitted.

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.

Maybe I could allocate a port to use for an additional low priority tcp candidate via configuration, or would I need to dive into the code for this? For example, I could supply the generated udp and tcp candidates in addition to a tcp:443? What are your thoughts?

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.

Re: Mediasoup – WebRTC Video Conferencing

#50

Post by manthideaal » Fri, Apr 03, 2020, 12:51 PM UTC

ibc wrote: post #47

manthideaal wrote: post #35

To understand the terms: webrtc, stun, turn, mesh, sfu, mcu, ice and trickle ice, there is (1). 15 minutes to understand what is all this about. What about IPv6 stun and turn?, it seems other people asked the same idea I thought: (2) bout all of this, one is the answer is: As IPv6 takes over the complexity of new networks, STUN and ICE will become irrelevant. I think that with the surge in video conferences and rtc,…

Thanks for the SPAM. Let's talk about whatever you wish to say.

In order to send a datagram to multiple IP the first, and naive idea, one can think of is to change the datagram protocol to allow for multiple destination. Today, 2020, is the right time. I am thinking about platforms that have hundred or thousand of simultaneous receiving ends, so that the branching point occurs near the destination. Again, googling this proposal is not new (1) RFC 1770, category informational.

Edited: It seem that RtcDataChannel can be used with SFU, example LiveSwitch in 2018, but they don't use multiple destination datagrams (3)