How does the STUN server get IP address/port and then how are these used?

Question

I'm trying to understand how WebRTC works and am having trouble understanding the role of STUN.

From what I understand in reading about STUN on various web-pages, such as rfc5389, or watching Google's 2013 presentation on WebRTC, the only thing STUN seems to do is tell the client what it's public IP address/port is.

However, looking at how one might implement a STUN server suggests they're a lot more involved, and seems to include things like fail-back support for UDP, TCP, and TLS-TCP, and handshaking where the client and server report what they expect their IP address to be and verify it against what the other side says their IP address is. For example, anecdotally, the jselbi's stunserver project has over 50 C++ files.

1. So STUN must be doing more than just reporting the public IP address/port?

Additionally, it doesn't make sense to me why a WebRTC client would even need to know its own public IP address. In Google's presentation video (at time 19:46) shows two peers that want to talk to each other from behind a NAT, and each peer is also communicating with a signalling server. This diagram suggests each signalling server doesn't know the peer's public IP address/port. But this diagram must be wrong: it shows the peer talking directly to the signalling server, but talking indirectly to the STUN server through the NAT. In reality, the peer would be talking to the signalling server through the NAT also, and therefore, the signalling server would already know the peer's public IP address/port.

From this, the things I am having trouble with are:

2. Any request from the client to the signalling server is going to include that client's public IP address/port in the IP header of the request. The same is true when the client talks to the STUN server, which is why the STUN server can respond with the public IP address/port... Is this right?

3. It seems to me that the way the two peers can then talk to each other is to hijack the open connection between the peer and STUN server: The peer opens a connection to the STUN server. The STUN server replies by stating what IP address/port has been set up for this request. And then that IP address/port is then forwarded on to the remote peer, where the remote peer starts sending messages on the connection that was originally opened for the STUN server... Is this correct?

4. ...or have I completely misunderstood what's going on?

Larkin

Answer 1

1. STUN servers only have the very simple role to return the public ip and port they received a UDP packet on to the client. What you are looking at is a server which implements TURN (described in https://www.rfc-editor.org/rfc/rfc5766) as well, which is a STUN extension that allows a client to open a udp port on a server and relay data.

2. The connection to the signaling server is done using TCP and that is not affected by NAT. The signaling server sees a incoming TCP connection but that data is not useful to establish an connection from the outside.

3. Yes. Well, almost, the media path uses UDP so there are no connections. A majority of NATs are forwarding anything that goes to the public ip/port to the initiating party. Symmetric NATs do not and are the reason TURN is needed. The whole process is referred to as either "udp holepunching" or more formally ICE (described in https://www.rfc-editor.org/rfc/rfc5245)

4. No, you got the "hijack" part which is one of the core ideas right. But NAT is more broken than you expected ;-)

Ipecac

Thank you for the answer, I am still mulling it over but I think the whole process is slowly starting to make more sense now. – Larkin