IPV6 and webRTC grumblings
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
IPV6 and webRTC grumblings
This restriction is there because the surveillance based ad industry was using ip addresses as a way to fingerprint and track users. Apple takes the view that users need to have expressed some trust in a site before their public IPs are disclosed. The measure of trust they use is if the microphone (or camera) permission has been granted to a page.
This is a reasonable proxy indication for trust on video conference apps.
IPV6 and webRTC grumblings
Unfortunately I'm working on a streaming app which only receives live video from a camera, so asking for a mic permission would be weird.
This cropped up because the camera is 5g capable - and modern 5g networks can give devices routable IPv6 addresses - which should reduce connection times and latency - if I can use them.
The trick (kindly pointed out here https://github.com/w3c/webrtc-nv-use-cases/pull/14#issuecomment-1647968028 ) is to use a STUN server.
IPV6 and webRTC grumblings
The ironic downside of using a STUN server is that it adds a round trip time (or possibly 2 if DNS is needed) to the setup time and discloses your IP address to an additional server that didn't otherwise need to know it.
Sigh.
Now on to making my home network IPv6 friendly again - which I lost in the move from #openBSD to #freeBSD
</grump>
IPV6 and webRTC grumblings
@steely_glint
Yes, That last toot was meant to end in Ellipsis, but i'll say it anyway..
You just never know what kind of ideas people got into with their IPv6 config.