Want 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.
I 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.
I'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?)
I 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.
every 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.
Ship one that uses Tunnel Broker to enable IPv6. Back when Teredo was a thing I wrote an article about how to turn a Raspberry Pi into an add on router for your IPv4 network. Essentially it would get a Toredo IPv6 prefix, then advertise the prefix to your LAN via radvd for stateless auto configuration. The effect would be that soon as you plugged one of these in it would instantly give every device on your LAN IPv6 connectivity without having to do a single thing besides finding a USB and CAT5e cable. Mostly was a proof of concept of course though I did run it like this for a bit. It worked quite well even if it didn’t give you your full bandwidth at all times.
My 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. 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.
You 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”.
> 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.
Any web browser could do a p2p call with just a bookmarklet and a chat room / comment section for trading ICE information.
Yes, I feel I am missing something here. Is this just a signalling server with optional SFU or is there more to it?
I 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
You should build that!
Isn't that true of anything a web browser can do?
They could but they're not, that's the difference.
If you think that method can become popular, then by all means... be the change.
Could you elaborate?
Want 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.
I 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.
I'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?)
I 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.
every 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.
Ship one that uses Tunnel Broker to enable IPv6. Back when Teredo was a thing I wrote an article about how to turn a Raspberry Pi into an add on router for your IPv4 network. Essentially it would get a Toredo IPv6 prefix, then advertise the prefix to your LAN via radvd for stateless auto configuration. The effect would be that soon as you plugged one of these in it would instantly give every device on your LAN IPv6 connectivity without having to do a single thing besides finding a USB and CAT5e cable. Mostly was a proof of concept of course though I did run it like this for a bit. It worked quite well even if it didn’t give you your full bandwidth at all times.
My 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. 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.
You 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”.
> 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.
You can user Tor and expose a service running on your lan to the whole world.
I can count to 30 before the onion service running my personal wiki loads. Tor is awesome but onion services are really, really slow!
Another reason to use ipv6 and just memorize your address to also not depend on dns