WebRTC not work with IPv6

[ailelix]

Which version are you using?

v1.6.0

Which operating system are you using?

• 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

1. Start the server
2. Publish with OBS/Browser
3. 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?

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
NetDump.zip