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

WebRTC: Not Quite Magic

alexfreska.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: WebRTC: Not Quite Magic

#41

Post by alexfreska »

vladimirralev wrote: post #34
AshleysBrain wrote: post #16

Earlier quoted context omitted.

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from two different IPs from the outside). This is not WebRTC's fault, it makes any peer-to-peer connections over the Internet hard, and given IPv6 adoption stands at around 3% right now insisting on IPv6 support would probably have been sufficient to prevent wides…

TURN/ICE is supposed to work just fine on symmetric NATs. Chrome even supports single-socket TCP relays, which can't be broken easily by any sane firewall. I personally have a few boxes testing it with only TCP 80 port allowed and it still finds a way to connect. A few tricks on the TURN side have to be employed but it's pretty robust. Whatever issue the OP has to be a bug or configuration issue. There are known prob…

Not all people have Chrome or latest version of Chrome and I think a fairly recent version is required to relay over TCP.

Re: WebRTC: Not Quite Magic

#42

Post by yperr_string »

AshleysBrain wrote: post #31
yperr_string wrote: post #28

Earlier quoted context omitted.

You make the problem sound like it's lack of IPv4 address space. That is true in some respects because the method of allocation of these addresses is not straightforward and has its own set of problems. But in actuality "the problem" the OP is encountering is that for the RTC developer/user, a publicly reachable IPv4 address block is too expensive. With a publicly reachable IP address (most ISP's will provide one, of…

UDP hole punching does not work with all types of NAT, e.g. symmetric NAT where a user can appear from the outside to be coming from multiple different IP addresses. (This makes the STUN server useless for telling the other peer where to connect.) Symmetric NAT is common in corporate networks, which I suppose is not the first place you'd find gamers (or you could just run LAN games with co-workers). I guess WebRTC is…

"UDP hole punching does not work with all types of NAT..."

I think what you mean to say is the STUN and TURN solutions do not work.

What else have you tried?

I personally do not use those solutions.

The last resort is for a peer outside the problem NAT to forward traffic. This is not true peer-to-peer (IMO) but it does work.

If what you suggest were true, that reliable peer-to-peer is "impossible" because of some types of NAT, then how do you explain the success of Skype?

If you give specifics about what exactly you were trying to do, and what exactly you did to try to accomplish this, maybe someone could offer suggestions.

I already knew that STUN and TURN have problems. That's why I do not even bother with those "solutions".

Re: WebRTC: Not Quite Magic

#43

Post by alexfreska »

yperr_string wrote: post #42
AshleysBrain wrote: post #31

Earlier quoted context omitted.

UDP hole punching does not work with all types of NAT, e.g. symmetric NAT where a user can appear from the outside to be coming from multiple different IP addresses. (This makes the STUN server useless for telling the other peer where to connect.) Symmetric NAT is common in corporate networks, which I suppose is not the first place you'd find gamers (or you could just run LAN games with co-workers). I guess WebRTC is…

"UDP hole punching does not work with all types of NAT..." I think what you mean to say is the STUN and TURN solutions do not work. What else have you tried? I personally do not use those solutions. The last resort is for a peer outside the problem NAT to forward traffic. This is not true peer-to-peer (IMO) but it does work. If what you suggest were true, that reliable peer-to-peer is "impossible" because of some typ…

I may be wrong but I don't think Skype works without at least a browser extension.

Re: WebRTC: Not Quite Magic

#44

Post by yperr_string »

zanny wrote: post #39
yperr_string wrote: post #28

Earlier quoted context omitted.

You make the problem sound like it's lack of IPv4 address space. That is true in some respects because the method of allocation of these addresses is not straightforward and has its own set of problems. But in actuality "the problem" the OP is encountering is that for the RTC developer/user, a publicly reachable IPv4 address block is too expensive. With a publicly reachable IP address (most ISP's will provide one, of…

> One wonders if every ISP customer were willing to pay the extra fees (if any) and requested a publicly reachable IP address, could the ISP's meet the demand? Well no, that is why all ISPs are using DHCP. Most offer static IPs for extra fees, but like fractional reserve banking that only works if all possible subscribers aren't trying to claim unique IPs each.

You may have misunderstood what I mean when I use the term "publicly reachable".

It is not only the static nature of the IP address that make it more suitable for peer-to-peer.

It is the ability to accept unsolicited inbound connections on any port.

The key word is "unsolicited".

Essentially, the user pays extra for the "privilege" of less stringent firewall rules.

Re: WebRTC: Not Quite Magic

#45

Post by yperr_string »

alexfreska wrote: post #43
yperr_string wrote: post #42

Earlier quoted context omitted.

"UDP hole punching does not work with all types of NAT..." I think what you mean to say is the STUN and TURN solutions do not work. What else have you tried? I personally do not use those solutions. The last resort is for a peer outside the problem NAT to forward traffic. This is not true peer-to-peer (IMO) but it does work. If what you suggest were true, that reliable peer-to-peer is "impossible" because of some typ…

I may be wrong but I don't think Skype works without at least a browser extension.

Skype does not require a web browser to do NAT piercing.

Nor does NAT piercing require a web browser.

Re: WebRTC: Not Quite Magic

#46

Post by alexfreska »

yperr_string wrote: post #45
alexfreska wrote: post #43

Earlier quoted context omitted.

I may be wrong but I don't think Skype works without at least a browser extension.

Skype does not require a web browser to do NAT piercing. Nor does NAT piercing require a web browser.

So Skype has a 100% success rate piercing NATs and does not require any fallbacks? Also you mentioned that you do not use STUN/TURN, what other solutions are there that allow for p2p data streams between browsers?

Re: WebRTC: Not Quite Magic

#47

Post by jmspring »

simon_vetter wrote: post #20
AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit. When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, ther…

> When they do, most pain points caused by NATs will go away, and that's not webrtc specific.

This is a naive statement since it assumes IPv6 support amongst the clients. At least here in the US, such support is fairly minuscule.

Re: WebRTC: Not Quite Magic

#48

Post by ay »

jmspring wrote: post #47
simon_vetter wrote: post #20

Earlier quoted context omitted.

Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit. When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, ther…

> When they do, most pain points caused by NATs will go away, and that's not webrtc specific. This is a naive statement since it assumes IPv6 support amongst the clients. At least here in the US, such support is fairly minuscule.

In the US, today, one in 15 clients accessing google.com / yahoo.com / facebook.com is doing it from an IPv6 address.

And it's more than double compared to a year ago [1].

While indeed this still qualifies as "relatively small", I think it grew out of the "miniscule" :-)

[1] http://6lab.cisco.com/stats/cible.php?country=US

Re: WebRTC: Not Quite Magic

#49

Post by makomk »

cpncrunch wrote: post #37
caio1982 wrote: post #8

While I think WebRTC is so fantastic it's nearly magical, I find it incredible how people using/creating it overlook networks' topologies problems that SIP and other VoIP folks already had to deal with (and went crazy doing so) a whole decade ago. NAT issues, STUN, all that is long known and yet I've never seen a fully working solution for peer-to-peer communication that won't be stopped by the simplest firewalls. Do…

The problem is that peer-to-peer isn't a very efficient way of doing group video chat to begin with...much better and simpler to just use a central server in that case.

Yeah. Sadly, in order to protect users against servers MITMing their video chats, the WebRTC spec was crippled to require that the central server in a group video chat have the keys required to MITM it.

I'm unfortunately not joking. The original spec allowed Javascript to directly provide an encryption key; this was removed because someone working for one of the browser vendors argued it would allow companies to MITM video chat (I think it was Google?) In order to make group video chat feasible, this was then replaced with a new feature where the central server sent out a copy of the encryption key over the encrypted RTP channel, meaning it now needed to have the keys to decrypt all the video passing through it.

Re: WebRTC: Not Quite Magic

#50

Post by rlpb »

AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

> Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are.

IMHO, this is a common misconception. IPv6 doesn't magically solve the problem.

In an IPv6 world, we will all need stateful firewalls (imagine a typical human's home router). These will generally be configured to allow all outgoing connections, and block all incoming connections - just like a NAT router effectively does today.

Now, you have the same problem all over again. How does the firewall know what new inbound connections to accept, and which to reject? We're back into the realms of packet inspection ("ALG") or protocols to explain to the NAT router what is required, such as NAT-PMP, uPnP etc.

Sure - each endpoint will have a unique address, and this is useful. But a direct peer-to-peer connection between these endpoints will be firewalled by default, except via the same (equally bad) solutions that currently solve the problem (badly) in a NAT world.

Post reply on HN