ICE vs STUN vs TURN

Question

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?

Dorset

note that neither the STUN nor the TURN server deal with SDP. That is the job of the signaling server. – Busiek

@PhilippHancke What do you mean by "That is the job of the signaling server"? Which part of the signaling server? – Dorset

your questions sounds like you are confusing teh STUN and signaling servers (which is quite a common confusion). The STUN server aids in the discovery of a public ip, the signaling server exchanges SDP and ice candidates (the latter are gathered from STUN and/or TURN servers) – Busiek

Answer 1

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.

Fatality

How "they send data to each other directly"? I mean, how they understand the destination port of the P2P connection? – Dorset

I got it, but I need more details. – Dorset

STUN absolutely will assist with NAT. That's what it's intended to do. It's just that it can't solve all traversals. – Utley

html5rocks.com/en/tutorials/webrtc/infrastructure remains one of the best introductions to this – Busiek

If I have a relay (TURN) server, do I need to transfer the SDP to each clients? It seem does not necessary because the clients are communicate with the TURN server, not each other? – Buckels

Does it mean stun is redundant, needless if turn exists? – Counseloratlaw

@Counseloratlaw STUN is much less expensive in terms of bandwidth costs for the provider, and also usually has lower end-to-end latency for the users, so normally it's preferred. – Fatality

Answer 2

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.

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

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

Rhinoplasty

I still don't understand how STUN works with restricted cone NAT. isn't it blocked because peer has different IP? – Adjuvant

don't know how it's done, but if you somehow managed to send a UDP packet or a DNS request and have the other peer IP-Address in your nat table. you are good. – Rhinoplasty

I'm trying to implement these protocols in a Python environment. I obtained the STUN response, but I'm unsure if I've done something wrong or if I need this signaling server. I took the port returned by STUN and opened a UDP socket with that port on 0.0.0.0. I did this for two nodes in different networks. Theoretically, should this be sufficient for them to communicate? Or have I misunderstood the concept? Note: I exec bind and listen on this port – Warrantable