Why can the STUN server reach the client behind NAT? In these two figures, why the 173.239.151.99(clientB) and the STUN server both know the clientA(192.168.0.1)'s public IP, why clientB can't reach clientA but STUN server can? Or to put my question this way: why we need STUN server after all? Say when clientA send request to clientB, there will be a binding between clientA's IP&port and NAT device's public IP&port in translation table, this " **mapping is created when a TCP SYN packet is sent from inside the NAT or when a first UDP packet is sent.** ", so when clientB sends response back, the translation table will help it to reach clientA. Then why on earth we need STUN? !figure!figure2

syntethic task ;-)

STUN can be used only with "full cone NAT, restricted cone NAT, and port restricted cone NAT"… but not with symmetric NAT. STUN is the protocol for clients, but clients, as usually, in real world are using symmetric NAT(unique port for any connection, dynamic translation)! In the real world servers are using full-cone NAT(static translation), and servers, as usually, gets connections from clients, which are already know ip:port…

However, formal answer: most "frequent" using of STUN it is sip client to server keepalive(udp), but there are also other usages: <


14. STUN Usages
At the time of writing, three STUN usages are defined: Interactive
Connectivity Establishment (ICE) [MMUSIC-ICE], Client-initiated
connections for SIP [SIP-OUTBOUND], and NAT Behavior Discovery
[BEHAVE-NAT]. Other STUN usages may be defined in the future.