network-programmingstunturnnat-traversal

STUN and TURN clarification

I need to establish a connection between a server and clients which can both be behind any type of NAT. For this purpose I have a dedicated host on the internet with clean IP for hosting STUN/TURN server. I'm not going to use WebRTC, I just want to use STUN/TURN server for messaging between clients and a server. After reading RFC's, SO, etc I have some questions left unclear:

  1. In which case STUN is used? In my understanding STUN is used only for Full-cone NAT. In all other cases TURN server must be used, because of host and/or port restriction. Is that correct?
  2. It seems I need a signalling server to notify clients about server address and vice versa. But as soon as client/server sends a message to the signalling server, I know their outer host:port, so I let each side know other's side host:port, each side can send messages to this signalling server containing peer's host:port data, which the signalling server can use to detect which peer this message is for and forward it to corresponding peer. At first sight this logic seems to me pretty straight-forward and my signalling server becomes a TURN server - is that how TURN server is implemented? But if so, I don't understand, why would I need a TURN server like "coturn", "reTurn", etc? I know they implement ICE, but how this ICE will work, if my signalling server received message from concrete host:port of a peer, so that is the only candidate that can be used for connection with the peer?
  3. In case of restricted NAT (port, address or symmetric), how long a client outer (public) port is open on router for receiving UDP datagrams? I read that TURN client sends refresh messages to server to keep channel open, is this how client also prevents ports from closing?
Solution

    1. STUN can bridge P2P connections for most NATs except the symmetric variety, which have unpredictable port mapping. TURN is needed for the latter.

    2. Signaling is typically done with TCP and a different socket. P2P media is typically UDP. So there's that distinction. You might discover the IP address with the signaling servers help, but you won't reliably discover the port. Even if both are TCP, you probably want a separate socket connection for the signaling service than the media.

    3. From my experience: anywhere from 1-2 minutes. Sometimes longer. In the absence of data flowing in both directions, have keep alive messages that flow every 45 seconds to keep the session from getting dropped.