5 ms·

I agree that WebRTC is super exciting, but if you want to deploy it into production, you need to have a STUN server and a TURN server. Until/unless we've all m

I agree that WebRTC is super exciting, but if you want to deploy it into production, you need to have a STUN server and a TURN server. Until/unless we've all moved to IPv6 without any NAT, we'll be stuck needing STUN and TURN to make it work.

qwantim1 6y ago
This is why I didn’t get really excited about WebRTC when I looked into it before. And the problem isn’t with WebRTC, it’s with the current infrastructure of the net that prevents some clients from just communicating directly without some element of centralization. And some of it’s our own fault. A cynical way of looking at it might be that WebRTC is being allowed because it helps scale the web while still being dependent on a central weak link of control. But it is what it is.
gcblkjaidfj 6y ago
> Until/unless we've all moved to IPv6 without any NAT hell will freeze before that happens. This is the bread and butter of ISP. Without NAT they lose too many revenue sources. They will hold to their NATs forever, claiming something like user security. While pushing for IPv6 to reduce their operating costs (those IPv4 costs add up)
- wmf 6y ago
  The majority of IPv6-capable ISPs are using prefix delegation to allow NAT-free operation. Heck, even phones are getting prefixes.
- detaro 6y ago
  Which ISPs do deploy/force NAT with IPv6? (I don't trust the industry enough to say there are none, but it'd be highly unusual)
- martyvis 6y ago
  What revenue sources does an ISP get for having NAT? In Australia, you pay retail ISPs to provide backhaul from the national broadband provider. I pay $10 per month extra for a fixed public IPv4 address, the public /64 for IPv6 comes free. That's it.
vorpalhex 6y ago
There are several free STUN services available, and you can fix a lot of connections with just STUN. STUN is just an IP lookup effectively, so it's very cheap to deploy. TURN is of course an entirely different beast because it's proxying all the data between clients. It's also where some more complex video stuff happens potentially. The good news is that there are solid, open source TURN servers available to run on your own hardware. The downside is that running those servers for non-trivial amounts of clients gets pretty resource intensive pretty quick.
- zip1234 6y ago
  So would STUN allow a connection to be established between a a user inside a LAN and internet user?
  - vorpalhex 6y ago
    In my experience you typically don't need STUN for that to work - the ICE flow of WebRTC will handle regular NAT[1]. It's typically when ICE can't determine the first few steps (eg your public address) that you need STUN to help you out. TURN tends to be needed in hostile networking situations like double NAT'd networks or very restricted networks like hospitals. [1] - https://webrtcglossary.com/ice/ https://webrtcglossary.com/ice/
mypalmike 6y ago
When used in a client/server context where the server has a public IP address, webrtc can be deployed entirely without STUN/TURN. The mechanism is peer reflexive candidates, wherein the server learns the address and port of the client based on the IP packet of the incoming ICE negotiation request. I have used this approach on production systems. For peer to peer, you'd have a tough time avoiding STUN/TURN anyhow.
saurik 6y ago
Only a specific form of low-quality NAT--one that is certainly often encountered but isn't at all common at the router or ISP level--is incompatible with WebRTC in a way that would cause you to need TURN.

qwantim1 6y ago

This is why I didn’t get really excited about WebRTC when I looked into it before. And the problem isn’t with WebRTC, it’s with the current infrastructure of the net that prevents some clients from just communicating directly without some element of centralization. And some of it’s our own fault. A cynical way of looking at it might be that WebRTC is being allowed because it helps scale the web while still being dependent on a central weak link of control. But it is what it is.

gcblkjaidfj 6y ago

> Until/unless we've all moved to IPv6 without any NAT hell will freeze before that happens. This is the bread and butter of ISP. Without NAT they lose too many revenue sources. They will hold to their NATs forever, claiming something like user security. While pushing for IPv6 to reduce their operating costs (those IPv4 costs add up)

wmf 6y ago
The majority of IPv6-capable ISPs are using prefix delegation to allow NAT-free operation. Heck, even phones are getting prefixes.
detaro 6y ago
Which ISPs do deploy/force NAT with IPv6? (I don't trust the industry enough to say there are none, but it'd be highly unusual)
martyvis 6y ago
What revenue sources does an ISP get for having NAT? In Australia, you pay retail ISPs to provide backhaul from the national broadband provider. I pay $10 per month extra for a fixed public IPv4 address, the public /64 for IPv6 comes free. That's it.

vorpalhex 6y ago

There are several free STUN services available, and you can fix a lot of connections with just STUN. STUN is just an IP lookup effectively, so it's very cheap to deploy. TURN is of course an entirely different beast because it's proxying all the data between clients. It's also where some more complex video stuff happens potentially. The good news is that there are solid, open source TURN servers available to run on your own hardware. The downside is that running those servers for non-trivial amounts of clients gets pretty resource intensive pretty quick.

zip1234 6y ago
So would STUN allow a connection to be established between a a user inside a LAN and internet user?
- vorpalhex 6y ago
  In my experience you typically don't need STUN for that to work - the ICE flow of WebRTC will handle regular NAT[1]. It's typically when ICE can't determine the first few steps (eg your public address) that you need STUN to help you out. TURN tends to be needed in hostile networking situations like double NAT'd networks or very restricted networks like hospitals. [1] - https://webrtcglossary.com/ice/ https://webrtcglossary.com/ice/

mypalmike 6y ago

When used in a client/server context where the server has a public IP address, webrtc can be deployed entirely without STUN/TURN. The mechanism is peer reflexive candidates, wherein the server learns the address and port of the client based on the IP packet of the incoming ICE negotiation request. I have used this approach on production systems. For peer to peer, you'd have a tough time avoiding STUN/TURN anyhow.

saurik 6y ago

Only a specific form of low-quality NAT--one that is certainly often encountered but isn't at all common at the router or ISP level--is incompatible with WebRTC in a way that would cause you to need TURN.