If a device has a publicly routable IPv6 interface, safari won't offer that address for a peer to use in a WebRTC call. Unless one of 2 seemingly unrelated things are true
a) the page already has microphone permission or
b) the page specifies an IPv6 capable STUN server.
The whole point of IPv6 is that you don't need NAT to share scarce IPv4 addresses - and so STUN (which figures out what your public IP address is) would be irrelevant for IPv6
"Set Phasers to Session Traversal Utilities for NAT, Scotty"!
"But Cap'n, It's 2023, we're using IPv6"
BTW, when is your #STUN obtained address not your address? - When your upstream WISP is multi-homed and the route to the stun server is not the route to your rtp endpoint. So, run your own stun server beside your media server, also avoids your address revelation concern. Of course, 'should' not be an issue with IPv6, but....
Does #IPv6 have something like #UPnP? Since stateful firewalls are necessary for complimentary security but there should be a way for a client to ask the router for exceptions
I think a typical household internet connection should be fully functional without having to change settings on the router at all.
Being able to function as a server is necessary for peer to peer topology, and P2P networking is needed for the lowest latency real-time communication: video conferencing, gaming, #VR...