- WebRTC Tutorial
- WebRTC - Home
- WebRTC - Overview
- WebRTC - Architecture
- WebRTC - Environment
- WebRTC - MediaStream APIs
- WebRTC - RTCPeerConnection APIs
- WebRTC - RTCDataChannel APIs
- WebRTC - Sending Messages
- WebRTC - Signaling
- WebRTC - Browser Support
- WebRTC - Mobile Support
- WebRTC - Video Demo
- WebRTC - Voice Demo
- WebRTC - Text Demo
- WebRTC - Security
- WebRTC Resources
- WebRTC - Quick Guide
- WebRTC - Useful Resources
- WebRTC - Discussion
WebRTC - Finding a Route
In order to connect to another user, you should find a clear path around your own network and the other user's network. But there are chances that the network you are using has several levels of access control to avoid security issues. There are several technologies used for finding a clear route to another user −
- STUN (Session Traversal Utilities for NAT)
- TURN (Traversal Using Relays around NAT)
- ICE (Interactive Connectivity Establishment)
To understand how they work, let's see how the layout of a typical WebRTC connection looks like −
The first step is finding out your own IP address. But there's an issue when your IP address is sitting behind a network router. To increase security and allow multiple users to use the same IP address the router hides your own network address and replaces it with another one. It is a common situation when you have several IP addresses between yourself and the public Web.
STUN
STUN helps to identify each user and find a good connection between them. First of all it makes a request to a server, enabled with the STUN protocol. Then the server sends back the IP address of the client. The client now can identify itself with this IP address.
So basically there are two steps −
For using this protocol, you need a STUN-enabled server to connect to. The great thing is that Chrome and Firefox provide default servers out-of-the-box for you to test things out.
For application in a production environment, you will need to deploy your own STUN and TURN servers for your clients to use. There are several open-sourced services providing this today.
TURN
Sometimes there is a firewall not allowing any STUN-based traffic to the other user. For example in some enterprise NAT. This is where TURN comes out as a different method of connecting with another user.
TURN works by adding a relay in between the clients. This relay acts as a peer to peer connection on behalf the users. The user then gets its data from the TURN server. Then the TURN server will obtain and redirect every data packet that gets sent to it for each user. This is why, it is the last resort when there are no alternatives.
Most of the time users will be fine without TURN. When setting up a production application, it is a good idea to decide whether the cost of using a TURN server is worth it or not.
ICE
Now we can learn how STUN and TURN are all brought together through ICE. It utilizes STUN and TURN to provide a successful peer to peer connection. ICE finds and tests in sorted order a range of addresses that will work for both of the users.
When ICE starts off it doesn't know anything about each user's network. The process of ICE will go through a set of stages incrementally to discover how each client's network is set up, using a different set of technologies. The main task is to find out enough information about each network in order to make a successful connection.
STUN and TURN are used to find each ICE candidate. ICE will use the STUN server to find an external IP. If the connection fails it will try to use the TURN server. When the browser finds a new ICE candidate, it notifies the client application about it. Then the application sends the ICE candidate through the signaling channel. When enough addresses are found and tested the connection is established.