STUN's approach does not work for symmetric NAT. See the "STUN and TURN" box for information on how it works.įigure 10: Peer-to-peer across the Internet STUN servers are used for discovery.
RTCPeerConnection takes full advantage of this same technology. This problem is by no means unique to WebRTC and was solved a long time ago in the SIP/VoIP world by means of STUN and TURN servers.
This gets complicated, because an endpoint – especially a browser on an end-user's device – does not know the topology that exists between it and the public Internet. The correct answer to this problem depends, among other things, on whether the local Internet connection uses domestic-grade cone NAT (in which a single public IP address/port pair allows packets from any source to reach a specific inside host) or commercial-grade symmetric NAT (in which access to an internal host via a given IP address/port combination is restricted to the single public host to which the internal host initiated communication beforehand). The local endpoint needs a way to figure out what public IP address/port number it ought to give the remote endpoint. However, it is more likely that each client is behind a different NAT, and the remote endpoint will not be able to route media packets back to the local endpoint's private IP address.
The chance that method will work just fine is small but definite, so WebRTC will include all of the device's IP addresses as ICE candidates. In an ideal world, an ICE candidate would simply be the host's own private IP address and a free port of its own choosing, and in the simple scenario of two endpoints communicating across the same LAN, that is indeed what would be used. This process as a whole is ICE, and discovery is the first part, in which each endpoint determines a list of IP addresses and port numbers (ICE candidates) that the remote endpoint might be able to use to send media back. A key piece of information that needs to be established during the signaling process is the IP address and port number on which the endpoint can receive a media stream from the remote endpoint, or the media return address.
0 kommentar(er)
