Hacker News Reader

Comment by Fr33maan | Hacker News Reader

WebRTC is known complicated to set up and quite unstable. Many companies have made a business of configuring WebRTC.

You can create a WebRTC datachannel in any modern browser with just one line of javascript:

     channel = new RTCPeerConnection().createDataChannel("foo", {ordered: false})

Then you can read from it with:

     channel.onopen = () => { ... }
     channel.onmessage = (event) => { ... }

This is widely supported in every modern browser.

What about the STUN, ICE etc stuff? Saying “you just open a connection” is only part of the story.

If you are talking to a websocket like server endpoint, hopefully it won't be behind NAT?

Actually, I'm currently working on an app using WebRTC, and from everything I've read you actually still need a STUN and in some cases a TURN server, even if you have a public IP:

https://bloggeek.me/turn-public-ip-address/

To be perfectly honest, I'm still fuzzy on the why, but numerous blog posts, stack overflow questions, and the Kurento forums agree. This being Hacker News maybe someone with chime in with the technical reasoning.

WebRTC negotiates a peer-to-peer protocol which operates like client/server but has issues with NAT/PAT and firewall traversal. Each peer will realistically only know about its local network and there will also likely be limitations on the peers even being able to communicate with one another directly.

STUN and TURN allow the negotiation to include services outside the local network so that you can relay signaling and stream data to a set of endpoints that both peers can use to communicate with one another. This could be the peers directly or it could be a set of 3rd party servers run by Google or someone open to the public and you can't assume any particular network topology.

This article is essentially claiming that for WebRTC to use TCP you have to be using TURN. While I am willing to believe I am wrong here (our product feels a bit crippled over TCP to the point where I just recommend you not use it, so if it isn't working I might not even notice), I am nearly certain this is not true.

You are right, ICE does support TCP. Not all ICE implementations support it though, probably where the incorrect anecdote comes from.

ICE TCP did get a little more limited recently in Chromium though [0] because of the TCP port scanning issue [1]

I have also heard that some gateways/firewalls/$x don't allow any non-TLS traffic, so you can't even establish ICE. In those cases the DTLS/TLS transport of TURN is nice.

[0] https://lists.w3.org/Archives/Public/public-webrtc/2020Feb/0...

[1] https://medium.com/tenable-techblog/using-webrtc-ice-servers...

You are probably right. But sounds like this would still be better solved by this light tweak to webrtc than by a new protocol.

Exactly. If WebSockets were an option, then WebRTC will be pretty trivial and absolutely doesn't require any STUN/TURN.

(The main issue, and this has nothing to do with the client API, is that WebRTC implementations tend to end up assuming unique ports for each user--which would be needed to help with NAT--but if you aren't behind NAT then the ICE layer already has a connection ID so you should be able to multiplex them all over a single open port.)

One big issue was also being able to demux DTLS traffic. You could do it off the 3-tuple of the remote host, but that would fall down sometimes.

I am really excited for DTLS connection ids[0] to land. Then you will have everything you need to run ICE+DTLS (and SCTP over that) and be able to demux/load balance it easier.

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connect...

This is simply not true. Unless things changed widely since I used WebRTC, this connects to nothing.

Leaving out the ICE will of course make WebRTC look palatable.

There pain point is running ICE, DTLS, and SCTP on the server.

That sounds like you need better software then :) Realistically what do you think the timelines are for QUIC?

When Bernard published the QuicTransport stuff I tried a few different versions and it only worked aioquic[0] (which is a really fantastic implementation)! But with 29 drafts and most servers not supporting them all feels like we still have some time to go.

So QUIC as a server is much less likely to happen then ICE/DTLS/SCTP which have implementations that work everywhere.

[0] https://github.com/aiortc/aioquic

> That sounds like you need better software then :)

No, it rather sounds like you have a hammer called WebRTC and you're attempting to use it on a nail called "bidirectional server/client communication".

Why deal with the complex protocol stack of WebRTC which solves, among other things, NAT traversal, mutual authentication and encryption independently of server certificates, multiplexing of data and A/V content on a single port and much more. And I say that as someone who absolutely loves WebRTC for A/V and secure P2P use cases.

There is a true gap of "UDP for the web", which this fills.

"WebSockets over UDP" don't need to be built on QUIC, but I'm assuming by the time you have added all the security features needed to make this as secure as WebSockets for web apps, you'll effectively end up with something equivalent.

Reply on news.ycombinator.com