Comment by Benjamin_Dobell | Hacker News Reader

Comment by Benjamin_Dobell | Hacker News Reader

Benjamin_Dobell

Is this hosted anywhere?

I created https://omen.tv/ just last weekend. Similar in that it's powered by WebRTC, but it's designed for casting your screen (e.g. Jackbox Games) to other people's TVs.

My greatest annoyances with WebRTC were:

1. WebRTC requires a STUN server, and despite the spec initially supporting default ICE servers, it has since been pulled out into an extension because browser vendors don't want to provide servers[1]. There are free STUN servers (Google etc.) but...

2. Double NAT clients. STUN is inevitably going to discover double NAT clients. The only way to connect these clients is through a proxy. Specifically a TURN server. Unlike STUN servers, these are not light-weight, and I can totally understand why browser vendors don't offer them by default. So inevitably any WebRTC use still requires a self-hosted TURN server.

3. Inconsistent access to streams across browsers. In particular the getDisplayMedia[2] API provides poor availability of the audio stream. Courtesy of Apple doing Apple things, I don't believe it's even possible to implement this API on macOS as there's no audio loopback device. I worked around this for my use-case by installing BlackHole[3] (which is great software!) However, the loopback device appears as an input e.g. like a microphone, so isn't technically the display audio.

For this all to be smooth I think all these pain points need to be addressed.

Issue 1 and 2 require NAT to be kicked to the curb, come on IPv6! Issue 3, requires Apple to expose a loopback device and browsers to implement support. These aren't insurmountable issues, but they're unfortunately out of our hands as day-to-day devs.

[1] https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConn...

[2] https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice...

[3] https://github.com/ExistentialAudio/BlackHole

The client-side script.js [1] appears to have a hard coded list of well known STUN/TURN endpoints, some with credentials.

The identity and access management is non-existent at this point of the project’s roadmap. A client needs the hostname of the Talk Node.js server along with a unique “room” name to connect, as far as I can tell after a quick glance of server.js [2].

[1] https://github.com/vasanthv/talk/blob/master/www/script.js

[2] https://github.com/vasanthv/talk/blob/master/server.js

I was playing around to create something similar and these problems were EXACTLY what I bumped into. STUN is a must for discovery, TURN is a must if both people are behind NATs, Apple support is meh...

So, to sum up, for a webRTC p2p app you need to:

1-3) The things you mentioned.

4) Code your own signaling server to transmit events like "call", "hung up", "room" tracking, etc.

> TURN is a must if both people are behind NATs

This is not what double NAT means. If both people are behind single NAT, STUN is enough.

I think it is also enough if one person (or both) are behind more than one regular NAT, which is what double-nat usually means.

Where STUN doesn't work is symmetric NAT [1], where different destination servers will receive a packet with different source ports, even if the original source port was the same.

It also doesn't work in a few, lesser-used NAT types [2].

[1] https://en.wikipedia.org/wiki/Network_address_translation#Sy...

[2] https://en.wikipedia.org/wiki/STUN#Limitations

Ad 2) this is false, double Nat doesn't automatically mean you need a proxy. It still depends on Nat type, it just increases the chances that one of them is a "hard one", to speak in terms of recent post about this problem:

https://news.ycombinator.com/item?id=24241105

I'm unaware of any NAT setup that allows double NAT'd clients to directly communicate with each other. Quite happy to learn different if you'll point me toward a specific NAT setup that'd allow this.

Just off the top of my head, the only way I could see this working is if the NATs themselves aren't transparent, and offer an API to manually map address/port pairs.

I don't understand how double NAT would cause a problem: you send a UDP packet out to someone on the public Internet (maybe STUN) and it will punch two holes; assuming you don't have low quality symmetric NAT, packets sent to the outer NAT on the egress port will be translated to the egress port on the inner NAT which will translate back to the original port on the client. Why do you think this would fail?

Why would it not allow this? Read the article I linked, it explains why double Nat is not really different.

A specific Nat setup would be my home connection, or pretty much anyone using the same ISP. It's CGN and then another Nat at home. Stun works fine with that.

Friendly NATs map, for UDP, e.g. (source address, source port) to (one of our outside addresses, port). Anyone who sends packets back to that outside address gets packets to you.

So, you bind 192.168.100.55:5555 and send a packet to a STUN server 1.2.3.4:3478. This creates a mapping between, 192.168.100.55:5555 and an outside port, we'll call it 81.82.83.84:12345. And the STUN server tells you back, in a reply, "you're 81.82.83.84:12345".

Then your friend sends a packet from his private address to 81.82.83.84:12345. It reaches your NAT, and is translated to 192.168.100.55:5555 and you receive it. Replying to this packet lets you send packets to him.

Yeah, my apologies. You're indeed correct.

I was incorrectly assuming that all NATs dynamically assign a new external port per destination IP-port tuple. As this is what I've observed in practice.

However, it looks as though many believe this only occurs for Symmetric NATs, and never Cone NATs. It seems the common terminology just isn't nuanced enough to explain what's really going on. Wikipedia[1] actually has an interesting paragraph regarding terminology:

> Many NAT implementations combine these types, and it is, therefore, better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate confusion by introducing standardized terminology for observed behaviors. [...] Specifically, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port.

The CGNATs I've encountered, which perhaps aren't representative, are mobile network CGNATs. By observation they were behaving like Restricted (either Address or Port) Cone NATs for inbound packets, but like Symmetric NATs for outbound packets. Hence, the source of my confusion in believing all Cone NATs exhibited this behaviour.

EDIT: I'm admittedly poor with the terminology as it's been years since I read the RFCs. I was only now able to express the above after doing a lot of refresher reading. I was coming at this based on experience implementing custom UDP P2P protocols, where I mostly just care about the worst case scenario; and had evidently assumed it more common than it is.

[1] https://en.wikipedia.org/wiki/Network_address_translation#Me...

can some one tell me why I want NAT kicked to the curb? I like the idea that you get slightly less info from me behind nat. I have 14-15 devices but if I understand, from the outside my NAT they look like one device. I like that honestly though maybe I shouldn't. That it's harder to do peer to peer is partly the point.

One and two read as if STUN and TURN are specific technologies build for WebRTC, but as far as I know, those are just the standard technologies for handling P2P-scenarios with consumer level usability in mind.

I think the biggest issue is that often you have to set up a STUN/TURN server in an extra environment. In the XMPP world, ejabberd has come to the point, where it brings most things you need today in a single package (XMPP, HTTPS, Lets-enrypt, STUN/TURN, ...). That way you add about 5 lines to a config file and get STUN and TURN with little effort. I like that simplicity and if you don't, you are still free to use an external STUN/TURN server.

> One and two read as if STUN and TURN are specific technologies build for WebRTC, but as far as I know, those are just the standard technologies for handling P2P-scenarios with consumer level usability in mind.

My apologies if it reads that way. They are indeed standardised web technologies used in a whole host of environments. For example, Valve run STUN servers for their (now deprecated, but very much still in use) Steam P2P APIs; which are backed by a custom UDP protocol.

For your points 1 and 2... you need those servers to be hosted away from your end points. ICE will not work otherwise and they are ultimately legit servers that someone has to work to keep running or pay for.

The STUN one is easy really but the TURN servers need to be able to proxy traffic. Twillio provides STUN/TURN servers and they are fairly cheap. I am sure there are others.

Since most IPv6 routers I have seen have default firewall rules similar to NAT (allow outgoing, and incoming only if part of a valid session), STUN servers would probably still be required, wouldn't they?

Not to my knowledge. With IPv6 you know each other's public address, and can thus "hole punch" directly. The problem with NAT is you don't even know the IP address you're attempting to establish a connection to.

Yeah; and this is why IPv6 is a bit evil and CGNAT+PMP (not that any clients are smart enough to do PMP correctly, which is stupid; and sadly not enough Internet is behind true CGNAT) is epic: you lose nothing (due to the explicit port mapping control) and get what amounts to free anonymity (unlike IPv6, which tattoos an identifier on you as if that's a feature).

Well, what you say is true to some extent, but there are some privacy extensions... And I don't think you should rely on having an obfuscated/shared IP for anonymity. There are better tools for this, like Tor, I2P, Freenet, etc.

IPv6 was designed back in the 90s, where we had much less concerns about tracking, privacy and anonymity. But IPv4 is even more ancient, and, make no mistake, CGNAT is not designed to make you more anonymous, so you could be fooled by a false sense of security.

Maybe we need to sell IPv6 as a way to track users to boost its adoption? And develop those privacy-conscious networks on top of it? Regardless, IPv4 and NAT are not consumer-friendly when it comes to self-hosting and p2p, so as long as these are the norm, software silos will be at an advantage.

You are right, I forgot about this. Though, as always, you need to obtain your peer's IP trough a side channel (also the case without firewall), if your firewall isn't too picky about answering to blocked requests, and doesn't meddle with source ports, punching a hole should be quite straightforward (one side just has to co-ordinate with the other to pretend the firewall didn't block the first incoming packet, right?).

I've been trying to find something like omen tv forEVER !!!. Webrtc existed for a while now but no one bother making something like this

I enjoyed sharing my entire full screen with omen.tv and watching infinity -- just like pointing a video camera at a mirror.

it is hosted here:

http://talk.vasanthv.com

STUN servers? I thought ipv4 was dead by now...

I thought low hanging fruits have all been collected by now.

Reply on news.ycombinator.com