7 ms·
Peer Calls: WebRTC peer to peer calls for everyone
- koolala 2y agoAny web browser could do a p2p call with just a bookmarklet and a chat room / comment section for trading ICE information.
- remram 2y agoIsn't that true of anything a web browser can do?
- Sean-Der 2y agoYou should build that!
- mettamage 2y agoCould you elaborate?
- koolala 2y agoWant to p2p video call? Here run this script. We don't really use our Browsers like terminals to dynamically run user code. 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.
- idiotsecant 2y agoAnd uncle Jimbo accidentally uploads his password cache running a script that was supposed to show him his favorite celebrity naked. The Internet is a common public square now. Unfortunately the public is, statistically, an idiot.
- koolala 2y agoOn most computers your files are like one big bowl of soup. I'm really excited for the future direction the browser file system is going in. I disagree with statistical fear and judgement. With OPFS it's hard to imagine someone doing that (especially in a native container OS)
- throwing_away 2y agoI'm interested in building in this area, but the problem as I understand it, is that NAT traversal is kind of unreliable, even if you can break the sandbox via console/bookmarklet or tell the user to paste code to a system terminal. 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 https://tailscale.com/blog/how-nat-traversal-works
- koolala 2y agoTo comment on the "tell me im wrong" part, not to tell you your wrong or this is right, but I haven't found obvious examples where WebRTC STUN fails where you'd convince network admins to a new kind of mesh network protocol in their corporate firewall. The obvious examples where a p2p internet connection doesn't work are obvious and acceptable failures. Like a p2p video call won't work in a military base? I have no idea honestly. Corporate and Government networks are not not my networks and I'm just happy p2p works on the open web at all.
- throwing_away 2y agoMy thesis is that your p2p node could contact some other p2p node that's willing to act as a relay and create a mesh network from entirely within a browser. 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?
- fidotron 2y agoYes, I feel I am missing something here. Is this just a signalling server with optional SFU or is there more to it?
- Sean-Der 2y agoI think people are excited because it’s easy to run yourself and well documented. 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
- ranger_danger 2y agoThey could but they're not, that's the difference. If you think that method can become popular, then by all means... be the change.
- dboreham 2y agoThe old school "Signaling via carrier pigeon" also works.
- ranger_danger 2y agoI applaud the real support for TURN (and TCP ICE) and the emphasis on explaining the (IMO very common) issue properly unlike so many other WebRTC projects that think the majority of people will never need it. 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.
- Sean-Der 2y agoI don't think Chrome or FireFox support passive ICE-TCP Candidates. 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.
- toast0 2y agoI've setup TCP and TCP+TLS for an SFU, and at least for my client base, it's barely used, but it is used. Almost everyone can do UDP. 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?)
- ranger_danger 2y agoMany public wifi spots like stores, hotels, airplanes etc. often block UDP (other than local DHCP).
- toast0 2y agoYeah, so your SFU or your TURN server needs to support TCP. 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.
- 1oooqooq 2y agoevery time i have to deal with ice and webrtc, i wonder if it is easier to ship a mirai style bot which would hack the modems from the lan side which is even easier than from the wan side, and and just add the portforwards.
- Sean-Der 2y agoMy dream would be if WebRTC Agents would experiment with Port Control Protocol. 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 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.
- marcodiego 2y agoYou can user Tor and expose a service running on your lan to the whole world.
- noident 2y agoI can count to 30 before the onion service running my personal wiki loads. Tor is awesome but onion services are really, really slow!
- SahAssar 2y ago> My other wishlist item is to allow mDNS for signaling. 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.
- IgorPartola 2y agoYou know what’s easier than all this happy crappy? Goddamn IPv6. How many engineer-hours have been spent trying to work around NAT and IPv4 which could have been spent implementing IPv6? Every browser tab could have its own publicly routable address if we wanted to. And the more work arounds we create the less pressure there is to get over the hump and treat IPv4 as the weird legacy protocol instead of treating IPv6 as the weird new protocol. 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”.
- Muromec 2y agoAnother reason to use ipv6 and just memorize your address to also not depend on dns
- m463 2y agoI think a lot of the nonsense on the internet happens because companies become a necessary intermediary for communication. 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.
- type0 2y agoSadly people are indoctrinated on how they should use computers/smartphones most users won't leave the mindset of "there's an app for that"
- dboreham 2y agoQuick note that this isn't peer to peer (WebRTC never is) but is a project that allows you to host your own server to facilitate WebRTC channels between browsers you want to provide service for.
- njtransit 2y agoWebRTC can absolutely be peer to peer. You just need some out-of-band method of exchanging ICE candidates. The connections in WebRTC are literally called "peer connections."
- Sean-Der 2y agoPeer calls can run in P2P mode or as a SFU. Different topologies are better for different use cases. 1:1 vs group calls in this case!