# Neither Denied nor Exposed: Fixing WebRTC Privacy Leaks
## 2 Media Connections  
There are two basic call topology types in WebRTC. In the simplest scenario, the peers are employing the same WebRTC service offered by the same webpage, creating a triangle model as Figure 1 depicts. On the other hand, if the peers' browsers are using services hosted by separate web servers, then the model becomes a trapezoid, inspired by the so-called Session Initiation Protocol (SIP) [10] trapezoid model, as illustrated in Figure 2. In this latter case, the two different web servers need a way to communicate, and thus signaling messages are used to set up, manage, and terminate the communication. The protocol used for this communication is not part of WebRTC; however, a standard protocol, such as SIP, JavaScript Session Establishment Protocol (JSEP) [11], or a proprietary one can be used [12]. In both the triangle and trapezoid models, the caller's and the callee's browser is communicating with the corresponding server, exchanging signaling messages using either HTTP or WebSocket protocol, in a way also external to WebRTC. Most of the times, P2P communication over the Internet is complicated despite the simplicity of the network architecture. Precisely, the peers might either be behind a firewall restricting network access, sitting behind a symmetric NAT box, or their router may forbid a direct connection to peers, so the use of a relay is necessary. In the context of WebRTC, the ICE framework offers a solution to the aforementioned problems. Specifically, as depicted in Figure 3, ICE enables the caller's and callee's device to be informed about their public IP:port address, by making binding requests to a STUN server. In case of using the same WebRTC service, the peers will most probably use a common STUN server; otherwise, different STUN servers will serve them. After the peers become aware of their IP:port address as seen from the STUN's perspective, they can easily establish a direct communication over  
Figure 1: WebRTC triangle network architecture. UDP or TCP, if UDP fails. If at least one of them is unable to do so in the presence of one or more of the aforementioned network obstacles, say, a non-STUN compatible NAT, then a TURN server can be used as a fallback mechanism. As illustrated in Figure 4, this server acts as an intermediate node to relay data packets between the peers. Note that, typically, a TURN server offers STUN functionality too. Moreover, due to the provision of real-time voice and video services, WebRTC preferably runs over UDP. Thus, in addition, UDP hole punching may be needed for establishing a direct connection between the peers successfully. Figure 3: Using a STUN server. Figure 2: WebRTC trapezoid network architecture. Browsers supporting WebRTC are able to make STUN requests and get informed about the actual private and public IP address of the end-user before passing this information to the JavaScript API. To initialize a connection to a remote peer, the local browser will use the RTCPeerConnection interface. Plainly, an RTCPeerConnection represents a WebRTC connection between the local machine and a remote peer, and thus provides all the necessary methods to the user's browser to connect to a remote peer and then maintain, manage, and monitor the established connection. To demonstrate a common scenario, we use an example where a client is behind a symmetric NAT. In such a case, the caller needs to ask the TURN server to allocate some of its resources for them, as the TURN server will be used as a relay to contact the other peer [6]. In the log entry in Listing 1, one can easily observe the information that the TURN server logs after the client initiated an \"Allocate transaction\", using an Allocate type of request. First, a time handler responsible for the process termination starts. The default lifetime of an allocation is 10 min, but the actual time is defined in the initial Allocate request [6].