Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

ICE vs STUN vs TURN

Tags:

webrtc

stun

turn

I've read that ICE is an agent on the WebRTC server which sends SDP information of users to STUN or TURN server.
STUN and TURN server gives this SDP information and makes a P2P connection for the users.

Is that true?
So, what is the exact difference between STUN and TURN server?
If the ICE agent configured with a TURN server, what would be happened with data flow? in this instance, TURN just act as a datagram-forwarder?

like image 322
M. Rostami Avatar asked Dec 26 '19 06:12

M. Rostami


2 Answers

This answer is for someone new to Webrtc

before we dive into the difference between STUN(Session Traversal Utilities for NAT) and TURN(Traversal Using relays around NAT), we need to understand how two deceives/peers can communicate via NAT(Network address translation) and its different methods:

  • Full-cone NAT, also known as one-to-one NAT, and less secure where anyone can connect to you and send data.
  • (Address)-restricted-cone NAT, sender IP-address must match with one of your NAT table visitors addresses.
  • Port-restricted cone NAT, like Address-restricted-cone NAT, but the restriction includes port numbers.
  • Symmetric NAT, allow a full-pair match only, most secure but not recommended.

STUN:

  • works with full-cone NAT,
  • works with (Address)-restricted-cone NAT.
  • works with Port-restricted cone NAT
  • doesn't work with Symmetric NAT
  • cheap to use and maintain.

TURN

  • works with Symmetric NAT
  • is the server/channel that forwards/relays the data packets between devices/peers like a reverse proxy at layer 4
  • expensive to use and maintain

ICE(Interactive Connectivity Establishment) is a protocol that lets two devices use an intermediary to exchange offers and answers even if the two devices are separated by NAT. it's a way of collecting information that describes the optimal path of connection between peers, and this information is put in an object called ICE candidate.

ICE candidates are objects consisting of the local-IP address, security & routing protocols like reflexive addresses (STUN) and relayed addresses (TURN), supported formats, etc... and all ICE candidates/collected information are sent to the peer via SDP.

SDP(Session Description Protocol) is an important part of WebRTC. it is a protocol or format as most people consider, used for negotiation between peers that describes ICE candidates, various audio and video codecs, network topologies, bandwidth, and other device information. the only question that remains is how do we send this SDP to the other peer? well, the right answer is up to you and we call it SDP SIGNALING.

SIGNALLING: refers to the signaling service or channel in the middle that can be anything (email, WhatsApp, postman, WebSockets, HTTP, pizza delivery guy). that will somehow manage to get the SDP information to the other peer.

signaling, STUN and TURN servers

in a nutshell, a STUN server is used to get an external network address, and TURN server is used to relay traffic if a direct (peer-to-peer) connection fails, a TURN server is a STUN server with additional built-in relaying functionality. whereas the Signaling server is used to let peers share service information to start the transmission of the peer-to-peer stream

exchange flow diagram

other resources to help you understand webRTC, NAT, and networking:

  • subnetting
  • NAT and IPV4 & IPV6
  • webRTC crash course
  • STUN VS TRUN SERVERS
  • STUN, TURN, and signaling
  • Quick start with webRTC
like image 160
Ahmed Boutaraa Avatar answered Oct 14 '22 18:10

Ahmed Boutaraa


TURN is a relay — both clients send data to the TURN server, which forwards it to the other client.

STUN is not a relay — the STUN server helps to "make the connection" between the clients (by discovering and exchanging their external host:port pairs), after which they send data to each other directly. However, STUN doesn't work with all NAT/firewall setups, so TURN is used when STUN fails.

like image 20
hobbs Avatar answered Oct 14 '22 19:10

hobbs