@mittorn @a1batross One problem with this NAT behavior check is that it's not reliable: If the STUN queries return the same external IP address, the client still cannot be sure the same address would also be used for connections from/to the peer's client. Another problem is that there's simply not much point in determining the NAT type beforehand, even if the check was reliable. Either STUN works or it doesn't, in which case you typically want to fall back to TURN.
@mittorn @a1batross So modern clients usually just perform a single STUN request, let the peer try to connect to the returned address, and fall back to TURN if that fails. Therefore, the NAT behavior check was removed from the newer STUN RFC (5349). There's a separate RFC (5780) which brings it back as an add-on, but it doesn't solve the problems (it just acknowledges them), and I don't think it's being used much.
Metalhead.club is a Mastodon instance hosted in Germany and powered by 100% green energy.