How WebRTC works

A primer on WebRTC

What does WebRTC do?

WebRTC is a technology that facilitates a direct, secure, and real time connection between two devices, avoiding passing through a server. It negotiates the shortest connection between the two devices. When both devices are on the same local network that means that the data isn't leaving that network.
It was designed primarily to magically enable video and audio connections between browsers, but can handle other types of data as well.

How is a connection established?


RTP stands for Real-Time Transport Protocol which uses UDP packets and provides some minimal rules for ordering.

For two devices to speak directly to each other without passing through an intermediary server, they need to find out some details about one another. Most devices are hiding behind firewalls and NAT boxes and don't even know their own IP. This signaling happens through the Freedom Robotics API and using STUN servers. These temporary connections are different from the actual media packets that will get sent between the two peers (the robot and the Pilot browser). Let's take a look at how this signaling happens with Freedom Pilot:

  1. The user clicks on 'Take Over' in the Pilot tab on the browser. This sends an HTTPS package through the Freedom Robotics API that contains where to find the media channels that should be exchanged.
  2. The device receives the webRTC request message from the API and responds. A process called ICE negotiation starts, which attempts several connection candidates that connect directly. If multiple connections succeed, the most favorable connection is picked and used as a backup. If no direct connection can be established in a timely manner, webRTC falls back on a relay server (a TURN server).
  3. The devices start communicating directly to each other using this connection. ALl data is encrypted end-to-end.

General WebRTC concepts are explained pretty well in several places already: bloggeek, webrtc ports and IP addresses

A STUN server uses hole punching to find out which port can be used on each device to communicate. Each device uses some ports to talk to these STUN and TURN servers, port 3478 or 19302, and 5349 for connections over TLS, which need to only be open outbound for the devices. The connections to the STUN and TURN servers use TCP packets, and the actual data connection will favor UDP, if available.


The STUN and TURN DNS addresses that should be passlisted in the firewall are: