Network Address Traversal

When a device, such as a computer, is working behind a home router, it acquires an IP address from that router. In order to serve multiple devices at home, the router assigns its own IP address in a private subnet but allows all devices behind the router to reach out to the Internet. In a typical case, the home computer gets an internal address, such as 192.168.1.101. A browser accessing normal web pages will use TCP to connect from the browser client to a server, so home routers work very well in these scenarios.

With WebRTC, however, the browser needs to send a media stream directly to another browser over UDP, as shown in the following diagram:

Since the browsers on both devices will only see the IP addresses acquired from the home routers, they will not be able to connect directly to one another, since these addresses are private. The Interactive Connectivity Establishment (ICE) protocol (RFC5245) was designed to resolve this problem, which does not normally exist in a traditional VoIP environment, since all of the device endpoints are deployed within the office network and hence no address translation is required.

The following is a simplified view of how ICE deals with NAT:

ICE uses the Session Traversal Utilities for NAT (STUN) protocol as a way to discover the server-reflexive address seen by a public server. Once a browser discovers all the addresses seen by public servers, it can use ICE to negotiate the connection with the peer. ICE parameters can be carried in SDP or in some other external signaling mechanism, and JSEP allows ICE negotiation independent of SDP negotiation.