WebRTC not work with IPv6

Which version are you using?

v1.6.0

Which operating system are you using?

[x] Linux amd64 standard
[ ] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[ ] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue

I deployed MediaMTX on a server with dual stack IP and a NAT. (actually a homelab) And I set up port forwarding to expose 8189 and 8889 with both tcp&udp, and then DDNS to the server. e.g. v4.example.com and dualstack.example.com The former has only A record and the latter has both A and AAAA record

When using dual stack host, clients prefer to use IPv6, which should be a good thing However, I found that whip/whep connections through IPv6 does not work well, while IPv4 does Seems that only handshakes can be established, stream data are not transfered:

2024/04/11 16:39:48 INF [WebRTC] [session 556ebd06] created by [Client IPv6 Address]:4045
2024/04/11 16:39:59 INF [WebRTC] [session 556ebd06] closed: deadline exceeded while waiting connection

An example of IPv4 working config:

webrtcLocalUDPAddress: :8189
webrtcLocalTCPAddress: ''
webrtcIPsFromInterfaces: no
webrtcIPsFromInterfacesList: []
webrtcAdditionalHosts:
  - v4.example.com
webrtcICEServers2: []

IPv6 does not work whatever I set in config, as long as I use the dual stack host in webrtcAdditionalHosts

webrtcLocalUDPAddress: :8189 or ''
webrtcLocalTCPAddress: '' or :8189
webrtcIPsFromInterfaces: no or yes
webrtcIPsFromInterfacesList: [] or enp2s0
webrtcAdditionalHosts:
  - dualstack.example.com
webrtcICEServers2: [] or Google STUN Server

Describe how to replicate the issue

Start the server
Publish with OBS/Browser
Read with Browser

By the way, I tried on multiple devices: Publish:

OBS 30.1.2 on Win & Linux Chrome on Win, Linux, and iPad

Read: Chrome on Win, Linux, iPad, and Android

Did you attach the server logs?

yes

Notice that I use caddy to mux the live and api So that the log may look weird, but it doesn't affect the bug Here's the Caddyfile if you need
xxx.com:21935 {
encode zstd gzip
import tlsconfig

handle_path /api/ { header { Access-Control-Allow-Origin: } rewrite /api / reverse_proxy :29997 } handle_path /live/* { rewrite /live / reverse_proxy :28889 } }



## Did you attach a network dump?

<!--
If the bug arises when using MediaMTX with an external hardware or software, the most helpful content you can provide is a dump of the data exchanged between the server and the target (network dump), that can be generated in this way:
1) Download wireshark (https://www.wireshark.org/)
2) Start capturing on the interface used for exchanging packets (if the server and the external hardware or software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card)
3) Start the server and replicate the issue
4) Stop capturing, save the result in .pcap format
5) Attach
-->

yes
> Sorry that I removed some of the dump out of security reasons
> I filtered the packages with src&dst of the server ip, and the clienthello packages are removed
> Feel free to contact me if any important information is filtered

[ServerLog](https://github.com/bluenviron/mediamtx/files/14944395/Log.txt)
[NetDump.zip](https://github.com/bluenviron/mediamtx/files/14944616/Dump.zip)

bluenviron / mediamtx