Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mediasoup – WebRTC Video Conferencing

mediasoup.org

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Mediasoup – WebRTC Video Conferencing

#61

Post by supermatt »

manthideaal wrote: post #51
supermatt wrote: post #40

Earlier quoted context omitted.

addressable !== routeable !== reachable. IPv6 will certainly REDUCE the need for STUN, but there are still (many) cases where you don't want to be "reachable by default", in which case you need a stable reference for negotiating routing and reachability (e.g. STUN).

IPv6 could have and address for "reachable by default", I find that very useful, also IPv6 allow many addresses so that is not wasteful.

Yeah, but if it’s reachable by default then it’s (by definition) open to the world. Otherwise (if you mean routable by default) you will still end up temporarily punching holes in your firewall, which you will need to close afterwards, and possibly recycling your ip so you aren’t still routable on that last used address. sounds like you would personally end up being a STUN server!

Re: Mediasoup – WebRTC Video Conferencing

#62

Post by ibc »

supermatt wrote: post #60
ibc wrote: post #58

Earlier quoted context omitted.

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

rfc3550 states that it is per destination ip/port tuple. So you should be able to support multiple connections per local port. Is it possible this is an oversight in the current implementation? I appreciate this isn’t TCP, which is why I have just read through all relevant RFCs.

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.

Re: Mediasoup – WebRTC Video Conferencing

#63

Post by supermatt »

ibc wrote: post #62
supermatt wrote: post #60

Earlier quoted context omitted.

rfc3550 states that it is per destination ip/port tuple. So you should be able to support multiple connections per local port. Is it possible this is an oversight in the current implementation? I appreciate this isn’t TCP, which is why I have just read through all relevant RFCs.

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.

TLS port was just a thought, as I want to reduce cases where turn server is used because of a limitation with scalability (65k connection limit per turn server due to a shared source ip). But our discussion has raised another issue regarding mediasoups limitation of one source per local port - which compounds the issue.

I’m replacing a web socket server with a data channel server. If I use mediasoup then I will need to listen over 4 ip4 addresses to support the 200k clients I can currently support on 1 ip address with web sockets. Not a huge deal right now, but if I want to support millions of user it means managing 40 or so ip addresses instead of 1 or 2.

Not knocking mediasoup at all, just now aware of a limitation that sounds like it doesn’t need to exist so seeing if we can do something about it.

Re: Mediasoup – WebRTC Video Conferencing

#64

Post by ibc »

supermatt wrote: post #63
ibc wrote: post #62

Earlier quoted context omitted.

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.

TLS port was just a thought, as I want to reduce cases where turn server is used because of a limitation with scalability (65k connection limit per turn server due to a shared source ip). But our discussion has raised another issue regarding mediasoups limitation of one source per local port - which compounds the issue. I’m replacing a web socket server with a data channel server. If I use mediasoup then I will need…

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).

Re: Mediasoup – WebRTC Video Conferencing

#65

Post by supermatt »

ibc wrote: post #64
supermatt wrote: post #63

Earlier quoted context omitted.

TLS port was just a thought, as I want to reduce cases where turn server is used because of a limitation with scalability (65k connection limit per turn server due to a shared source ip). But our discussion has raised another issue regarding mediasoups limitation of one source per local port - which compounds the issue. I’m replacing a web socket server with a data channel server. If I use mediasoup then I will need…

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…

Isn’t that what the SSRC is for? I.e you use the SSRC (sent as part of media in the SDP) to identify the stream, rather than trusting an authentic stream is the only one to send to an open port? At least, that is how I understood the (multiple) rfcs. Not an expert here by any means.

Re: Mediasoup – WebRTC Video Conferencing

#66

Post by ibc »

supermatt wrote: post #65
ibc wrote: post #64

Earlier quoted context omitted.

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…

Isn’t that what the SSRC is for? I.e you use the SSRC (sent as part of media in the SDP) to identify the stream, rather than trusting an authentic stream is the only one to send to an open port? At least, that is how I understood the (multiple) rfcs. Not an expert here by any means.

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.

Re: Mediasoup – WebRTC Video Conferencing

#67

Post by supermatt »

ibc wrote: post #66
supermatt wrote: post #65

Earlier quoted context omitted.

Isn’t that what the SSRC is for? I.e you use the SSRC (sent as part of media in the SDP) to identify the stream, rather than trusting an authentic stream is the only one to send to an open port? At least, that is how I understood the (multiple) rfcs. Not an expert here by any means.

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

Many Thanks. Sorry to be a bother :) Ill have a play around and see what I can get working for my usecase.

Re: Mediasoup – WebRTC Video Conferencing

#68

Post by deepinder10 »

The performance as mentioned on webrtchacks seems promising, I was planning to go with openvidu but now i am more inclined towards mediasoup. My only concerns are, please provide simple tutorials with demo and code explanation (it would be 30 lines of code) so that beginners like me easily understand it. If you check out openvidu they have provided demos for every use case with explanation. It is hard for a beginner to understand all this stuff and there isn't a js v3 broadcasting demo available. Also if you could mention some performance results on various machines like c5.large, c5.xlarge, c5.2xlarge with number of participants it would be helpful. Thanks a lot

Re: Mediasoup – WebRTC Video Conferencing

#69

Post by deepinder10 »

anovikov wrote: post #4
ofrzeta wrote: post #3

Earlier quoted context omitted.

Sure, the website could be better. Here's a demo https://v3demo.mediasoup.org/ And here's the source code for the demo: https://github.com/versatica/mediasoup-demo/ Libs for native apps: https://github.com/haiyangwu/mediasoup-client-android https://github.com/ethand91/mediasoup-ios-client

Libs for native apps suck. But, it is compatible with React Native and works fine there. In general, i recommend it. Only media server that i saw working (slightly) better is Jitsi, but it is 10x more cumbersome and time-consuming to learn.

making a single customisation in jitsi is a cumbersome task. You have to accept it how it is.
Post reply on HN