Hacker News Reader

Comment by jbaudanza | Hacker News Reader

This is great! I just spent the weekend researching WebRTC for a language learning project I'm working on. I have a few questions about SFUs. Maybe someone here can help.

1. SFUs seem to be the clear winner for multi-party calls. Do they provide any advantage for 1-on-1 calls over peer'd connections? It seems like using an SFU in this case would double the number of connections, and hence double the connection issues.

2. Do clients communicate with SFUs by establishing a normal RTCPeerConnection like they would with another peer? Or is there some other video sharing protocol for SFUs that I don't know about?

View on HN

1. Not as much benefit for 1-on-1 except that you can guarantee connectivity without a STUN server, can get a bit more predictable network paths from client to server than client to client, and can abstract choosing the best simulcasted stream quality. It won't double the connection count, but it can make you upload unnecessary streams in the case of simulcast, because the client won't be the one determining which stream quality is best, it'll just send multiple.

2. Yup, SFU acts like another client. Some libs do one connection for up and one for down or other ways to handle stream multiplexing, but overall it's the same WebRTC peer connections.

Thank you! This is very helpful! We are doing mostly 1-on-1 calls, so I'm considering if peered connections would be better. They're certainly cheaper. I hadn't considering simulcasting multiple quality streams. That's something to think about.

By "doubling connection count" I mean CLIENT <-> SFU <-> CLIENT is twice as many as CLIENT <-> CLIENT.

Some do peer to peer for 1:1, then upgrade to actually using the SFU for more participants. But that's a challenge on its own, so when more than 1:1 is expected, you might just prefer to use SFU from the start, and save the hassle for when to switch between those two models

Thank you! That’s good advice

Reply on news.ycombinator.com