@mittorn @a1batross Long story: The main purpose of STUN is to let a client that sits behind a NAT figure out its public IP address. Usually with the goal of establishing a p2p connection with another client. This will often work, but not under all circumstances: There are NAT types where the client's public IP address depends on the target IP address. So the external IP address as seen by the STUN server might be different from the external IP address the peer's client could talk to.
@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.