CODEWITHSUNDEEP
webrtc
Krystian
Krystian

Reputation: 2290

WebRTC - TURN and ICE functions

I'm trying to understand a concept of WebRTC. As I found in some descriptions (for example here http://www.innoarchitech.com/content/images/2015/02/webrtc-complete-diagram.png), there is such a way of making a connection:

  1. Call STUN, to get your IP:port address.
  2. Get some channel from TURN - with that channel you can send info to other peer.
  3. Send to other peer ICE candidates.
  4. Accept ICE candidates with other peers- start a call.

The question is, what do we need ICE candidates for? We know our IP, we can send it to TURN therefore to other peer, and on TURN we have a nice connection with other peer- so we don't have to scary about NATs. Why except that we are sending ICE candidates (why many?), and why we need to use them?

Upvotes: 2

Views: 1307

Answers (2)

jib
jib

Reputation: 42430

TURN is typically used only as a fallback when a direct peer-to-peer connection cannot be established. The latter is the hard part, and is what ICE is for.

Always using TURN, is an option, but a bit of an edge-case.

Upvotes: 0

gogasca
gogasca

Reputation: 10058

We have 3 main concepts here:

  • ICE
  • TURN
  • STUN

The ICE negotiation is not that simple... To execute ICE, UAs have to identify all address candidates, transport addresses. Transport addresses are a combination of IP address and port for a particular transport protocol. There are three types of candidates:

  • Host Candidate – transport address associated with a UA’s local interface
  • Relayed Candidate – transport address associated with a TURN server (can only be obtained from a TURN server)
  • Server Reflexive Candidate – translated address on the public side of the NAT (obtained from either a STUN server or a TURN server)

enter image description here

After UA1 has gathered all of its candidates, it arranges them in order of priority from highest to lowest and sends them to UA2 in attributes in an SDP offer message. UA2 performs the same candidate gathering and sends a SDP response with it’s list of candidates. Each UA takes the two lists of candidates and pairs them up to make candidate pairs. Each UA gathers these into check lists and schedules connectivity checks, STUN request/response transaction, to see which pairs work. Figure 3 shows the components of the candidate pairs that make up the UA check list.

ICE assigns one of the agents as the “Controlling Agent” and the other as the “Controlled Agent”. The controlling agent used the valid candidate pairs to nominate a pair to use for the media. There are two nomination methods that can be used:

  • Regular Nomination The checks continue until there is at least one valid candidate pair. The controlling agent picks from the valid pairs and sends a second STUN request on that pair with a flag to tell the peer that this is the one that is nominated for use.
  • Aggressive Nomination The nomination flag is sent with every STUN request, once the first check succeeds ICE processing for that media stream is finished and a second STUN request is not needed.

Each candidate pair in the check list has a state associated with it. The state is assigned by the UA once the check list has been computed. There are five possible states:

  • Frozen This pair can only be checked after being put in the waiting state. To enter the waiting state some other check must succeed first.
  • Waiting As soon as this is the highest priority pair in the check list a check will be performed.
  • In-Progress A check has been sent for this pair and the transaction is in progress
  • Succeeded Successful result from pair check.
  • Failed Failed result from pair check.

The link below includes more information and diagrams of the ICE flow.

Reference:

Upvotes: 3

Related Questions