If by WAN-
IP means Internet accessible
IP then you don't even need STUN or any sort of tunneling/forwarding, STUN and TURN and other protocol used for either bypass the NAT and firewall restriction or to provide privacy (hide
IP's from each others) in case peer-peer connection.
So what you are saying is that if I run Websocket server behind a firewall that blocks all incoming connections to the corporate network and isn't configured to route incoming traffic to the right computer in the corporate network, with websockets it would just work I get to bypass the firewall and all clients that are runing on the mobile phones get connections to that server application?
It sound's kinda too good to be true.
No, I am sorry, may be it is language barrier, what i said is either you have a public accessible
IP then you don't need any thing, or the server is not accessible because it is in NAT different form the client (in this case a mobiles), in this case the server must use tunneling, as example in case of STUN, the server will connect to the Internet public STUN server and register a binding, any clients want to reach your server
can or must bind to that STUN server and establish a connection,
1) "must", if there is no other way like the server is behind a NAT (with forwarding) or behind a firewall (which doesn't allow incoming connection).
2) "can", the client want to hide its
IP from the server for privacy reason, even when the client can
access lets say delphipraxis.net directly, but for privacy it want to hide its
IP from delphipraxis server so it uses a public STUN server used also by delphipraxis.com server, hence the only one will know its
IP is the STUN server, this case is like what Signal (social app) doing but relaying peers audio/video calls through a server to make sure none of them can see the other
IP, and of course make sure both can connect, but it is optional and you can allow direct calls, then if one of them can reach the other directly then will connect, but in this case both will know the
IP for each other.
Now does that clear things ? i hope so, but let me know if you have questions.
ps: TURN provide almost same as STUN even better but with differences, TURN need two clients (to be exact two peers, clients or server or what ever) to know some sort of a token for each other before register and bind traffic using TURN, so unless you are developing server with hardcoded clients tokens or you have another network structure to manage these tokens (tickets, key ...) there is no way to connect, even if you succeeded in that for server/client infrastructure, the server must establish a dedicated connation for each client to meet at TURN server.
While STUN allow clients to connect to server and having the server to
access or refuse these connection over one server-to-STUN connection, the custom traffic you want to exchange will be in a thing called attributes in the messages, so your behind firewall server that can't accept incoming connections, will be able to establish connection and accept clients on STUN server.