Why WebRTC needs the local IP of the remote peer?

Question

When we send request to some STUN server, we receive our IP:port pair as the external server see it. Then, we include our local IP:port pair on which the browser is binded in this "probability list of possible connection targets", and send it to the remote client through the WebRTC network (actually, i never fully understand - on which step or where the user ID is resolved to it's IP and from where the remote client IP is known...?).

But why we need the local IP address and port? Well, for the port, my explanation is that some NAT firewalls can be configured to put same local port to the external requests (rewriting only the IP), and then info like can be useful, but where is IP needed here?

Answer 1

The local IP as seen by the browser may very well be a viable connection option. That's why it's included.

The link mentioned in the comment actually displays ALL ICE candidates generated for the connection. Your local IP address is the most basic one, which the browser adds itself. That's the one candidate you get when you run webRTC without STUN. But that address could well be a real IP or private and viable on the local network. Now if it's behind NAT, the browser cannot know the routers external IP - that's the connection option STUN detects while at the same time poking a hole into the NAT for the connection. (And if that doesn't work, there are also TURN servers, which will also show up as an ICE candidate with their own IP.)

ICE candidates are essentially a list of potential addresses the other end could possibly connect to. Anything that's detectable or might work is included, not only the STUN responses or the local IP(s). The other end then uses these to try to establish the actual media/data (RTP) connection.

I'm not sure what you mean by "user ID", but these ICE candidates have to be given to the other client through a separate method or signaling layer. That's how the the actual connection is made - how that is done exactly is not defined as part of webRTC and can really be anything. A popular transport layer are websockets. Essentially the two clients must already be communicating in some form before webRTC comes into play.