webrtc.listen refuses an IPv6 address, and the server drops IPv6 candidates (server/move-channel.cjs), so a phone on Verizon never runs WebRTC over its IPv6 -- that resets its whole data session, the same reason voice uses voiceIceServersIpv4. On a server with no IPv4 address the WebRTC channel is therefore off and every player's packets ride the WebSocket. Nobody hosts that way yet.
What it would take:
- Test first: does Chrome, and Safari, ask TURN for an IPv6 relay address (RFC 6156
REQUESTED-ADDRESS-FAMILY) when the peer only has IPv6? coturn supports it. If browsers never ask, phones on a v6-only server stay on the WebSocket and the rest of this is only for non-phones.
- Let
webrtc.listen bind IPv6 ([::]:5153).
- Accept IPv6 candidates from clients that are not kept on IPv4; keep filtering them for phones.
- Offer phones the IPv4 TURN servers (
voiceIceServersIpv4) for the move channel, which today gets STUN only: phone -> turn4 over IPv4, relay -> server over IPv6.
BZFlag clients and the BZFlag list server stay IPv4 regardless; that is upstream's limit. Related: #189.
webrtc.listenrefuses an IPv6 address, and the server drops IPv6 candidates (server/move-channel.cjs), so a phone on Verizon never runs WebRTC over its IPv6 -- that resets its whole data session, the same reason voice usesvoiceIceServersIpv4. On a server with no IPv4 address the WebRTC channel is therefore off and every player's packets ride the WebSocket. Nobody hosts that way yet.What it would take:
REQUESTED-ADDRESS-FAMILY) when the peer only has IPv6? coturn supports it. If browsers never ask, phones on a v6-only server stay on the WebSocket and the rest of this is only for non-phones.webrtc.listenbind IPv6 ([::]:5153).voiceIceServersIpv4) for the move channel, which today gets STUN only: phone -> turn4 over IPv4, relay -> server over IPv6.BZFlag clients and the BZFlag list server stay IPv4 regardless; that is upstream's limit. Related: #189.