CODEWITHSUNDEEP
webrtcnatstun
JacopoStanchi
JacopoStanchi

Reputation: 2146

Are STUN servers really necessary?

In the WebRTC signalling process, I have to find my own public IP address with my port by doing a request to a STUN server. But does it really need to be this complex?

Couldn't I just send a request to the router of my subnet and get its IP address and the port it opened for me? Or even better, I store directly my public address in my computer and the router notifies me whenever it changes. The browser would give an API to get this public address directly. No need to use a STUN server. Why don't we do this instead?

Thank you for your help.

Upvotes: 3

Views: 1933

Answers (1)

selbie
selbie

Reputation: 104514

These are all great questions.

Couldn't I just send a request to the router of my subnet and get its IP address and the port it opened for me?

There's an old protocol called uPnP that will dynamically open a port mapping for you - provided the router supports it. A lot of routers used to support it. Not sure how standard it is now.

Even if routers were intelligent and there was a standard signaling mechanism in place, STUN (or something equivalent for STUN is still needed) for the following scenario.

Carrier NAT is when your ISP is sharing a public IP address with multiple routers. That is, your router's public IP address as configured by the ISP when it starts, is really just another private IP address. Upstream, there's a "bigger router" that is sharing the public IPv4 address with multiple other customers. That is, your PC might think it's IP address is 192.16.1.2, and your router reports that it's own IP address is 10.0.0.2. And the actual public IP address, 1.2.3.4, is shared with other customers. STUN solves this problem because the outbound packet to the public STUN server will go through both NATs - creating port mappings along the way.

Or even better, I store directly my public address in my computer and the router notifies me whenever it changes

Because establishing an effective P2P/WebRTC connection is more than knowing your public IP Address. It also involves knowing what "port" to use as well. While most routers will attempt to preserve the local port of the socket the client PC is using in the mapping (e.g. 10.0.0.2:9876 maps to 1.2.3.4:9876). This isn't always the case - another node could be using port 9876 on your network and/or many NATs just pick a randomly available port for the mapping. At the end of the day, you have to signal to the other side of your P2P/WebRTC connection "which IP" and "which port" to use.

The browser would give an API to get this public address directly.

There are plenty of sites such as whatismyipaddress.com that will tell you your IP address. But if there's a HTTP proxy server involved (explicitly configured on the PC or silently deployed on the network), the web service will only see the proxy IP address. Further HTTP(S) is a TCP based protocol. STUN and WebRTC are UDP based.

Upvotes: 8

Related Questions