Peer Calls: WebRTC peer to peer calls for everyone
github.com
github.com
I know Firefox now supports outgoing TCP ICE, but what about incoming TCP connections? I wasn't able to find an answer easily from googling.
The assumption is that two clients are in the same LAN they would use UDP anyway. If are in two differents NATs doing traversal with TCP isn't support. I have read that it is possible, not something I have tried myself though.
For 1:1 calling, I suspect the number of peers that can do peer to peer TCP, but not UDP is so small that it's not worth bothering.
But that doesn't answer your question, sorry. I know the application I work on doesn't listen for incoming tcp on clients, but I think there is support for it in the WebRTC library. (Not sure if Firefox pulls that in, or wrote their own implementation?)
But if you're on public wifi, chances are you can't get inbound tcp to work. And the majority of the peers you might connect to probably can't either. It's not worth the effort to eek a tiny % more peer to peer when you have to build the relay server fallback anyway.
Different topologies are better for different use cases. 1:1 vs group calls in this case!
It would be like a different timeline where a programming console is not a 'dev' feature and anyone is equal at using code. If our computers become smart like AI then all friction for programming could be erased.
It's hard to elaborate on a world where bookmarklets and user scripting becomes a normal thing where we freely tap into our browser's capabilities.
The Internet is a common public square now. Unfortunately the public is, statistically, an idiot.
For some people (behind CG-NAT), it may just not be possible to get an inbound port at all, so there may be two nodes that cannot directly communicate in the network.
The traditional solution is some kind of relay (see: TURN, skype's supernodes).
As far as I know, and maybe somebody can point me in the right direction, there is no technology available for a webrtc overlay mesh network where some nodes can relay for other nodes. I know webtorrent exists, so it should be possible.
You can see evidence of this problem in this project's README:
> When a direct connection cannot be established, it might be help to use a TURN server. The peercalls.com instance is configured to use a TURN server and it can be used for testing. However, the server bandwidth there is not unlimited.
What's needed, IMO, and please HN tell me why I'm wrong -- is a browser-to-browser mesh overlay system.
I would love to see an array of nodes (across varying levels of NAT) saturate their connections by all relaying to each other as a decentralized stress test that reports real-world p2p bandwidth between providers.
--
Btw, Tailscale has an excellent post on this topic: https://tailscale.com/blog/how-nat-traversal-works
If your side of NAT sucks and STUN fails, you'll probably only be able to connect to someone that has a NAT-traversal friendly configuration. But since you're able to reach them, they could act as a relay to the rest of the overlay network from behind your restrictive NAT.
Imagine I'm running one node that's willing to relay on a publicly accessible IP. If I'm the only node willing to relay on a public IP, then we've pretty much got TURN without the daemon.
If multiple nodes are willing to relay, then we have a general purpose mesh network within the browser sandbox that works on mobile?
Haven’t given up on the idea though!
I find the code base easy to understand since it’s built by one developer. It’s a consistent read and not sprawling/pointless duplication
If you think that method can become popular, then by all means... be the change.
I don't know if it is the answer, but a world without dependence on STUN servers sounds pretty amazing. I can see why it would feel like kludge, but how could would it be to remove that dependency.
My other wishlist item is to allow mDNS for signaling. Something like https://github.com/pion/offline-browser-communication. It is so silly that I need to exchange a Offer/Answer using a remote server to start a session with a IP Camera in my LAN.
If you load a webpage with from a mDNS address of the camera what other steps are needed? Your browser and the camera should be able to exchange SDP and connect without any third party.
I guess engineer activism is all there is really left to do. Enable dual stack, write your code to be IPv6-first (it can automatically do IPv4 connectivity if enabled so really you only need to support one stack and the OS will translate for you; this doesn’t mean you can avoid having IPv4 addresses if you want to have your service IPv4 accessible, just that your code can pretend like every address is an IPv6 address). Test your code without IPv4 connectivity. If you reference localhost, don’t use 127.0.0.1 preferring localhost instead. Don’t be the reason the next engineer has to say “well this codebase isn’t IPv6 compliant so we can’t enable it”.
Is there a safe protocol to allow applications inside a network to automatically ask edge firewalls for temporary port forwards (or port unblockings, which would be all that would be needed with routable IPv6)? I still can't see how that could be made safe, though: how would the firewall know that the request was coming from a user on the network, and not malware (or a user being duped by malware)?
[0] https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...
Instead we could implement a better version of UPnP or just open a set of ports specifically used for P2P connections and allow the browsers to open those ports when they expect an incoming connection.
Firewalls serve a purpose but make no mistake they don’t prevent you from bypassing them. Clearly P2P connections are still made all the time.
Your specific question of “how do I know it’s not malware?” doesn’t make much sense. First most default firewalls allow outbound connections which is what malware would do. If you have malicious code running on your machine, the game is already lost.
The job of the firewall is two-fold. First it protects against unwanted flood of traffic to devices whose local resources are too limited to do the filtering themselves. The second is to keep ports closed to hosts outside of your LAN that they shouldn’t have access to. Say you misconfigured your NAS network file system and allow connections from anywhere. Oops. Your firewall protects against that.
But unless you effectively disconnect your laptop from the internet, the firewall won’t stop it from connecting to a remote host. At that point if you open a TCP port that is how you signal that you are requesting an incoming connection. Which is exactly what the current WebRTC system does except it also has to jump through a lot of hoops to establish the connection (steps that any malware would be able to take as well.)
I believe this would be solved except...
"It is difficult to get a man to understand something, when his salary depends on his not understanding it."
So companies NEED to be intermediaries "for security", "for discovery", because we need TURN, (...and for subscriptions, for ad serving, for revenue idea of the week, etc)
If more folks were able to use peer to peer communications (think families, not phishing/trolling/etc) a lot of this nonsense would go away.
most users won't leave the mindset of "there's an app for that"