4 ms·
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
by ranger_danger 2y ago
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.
- 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.