What are ICE Candidates and how do the peer connection choose between them? [closed]

Question

I newly wrote a simple chat application, but I didn't really understand the background of ICE Candidates.

When the peer create a connection they get ICE Candidates and they exchange them and set them finally to the peerconnection.

So my question is, where do the ICE Candidates come from and how are they used and are they all really used ?

I have noticed that my colleague got less candidates when he executes the application on his machine, what could be the reason for different amount of Candidates ?

Grumous

Maybe not that easy to digest but you could check RFC 5245. – Veloz

There is a nice presentation, which can explain concepts of ICE, STUN and TURN viagenie.ca/publications/2008-08-cluecon-stun-turn-ice.pdf – Coop

I recommend to look at the link provided by Krystian! – Befall

Answer 1

the answer from @Ichigo is correct, but it is a litte bit bigger. Every ICE contains 'a node' of your network, until it has reached the outside. By this you send these ICE's to the other peer, so they know through what connection points they can reach you.
See it as a large building: one is in the building, and needs to tell the other (who is not familiar) how to walk through it. Same here, if I have a lot of network devices, the incoming connection somehow needs to find the right way to my computer.
By providing all nodes, the RTC connection finds the shortest route itself. So when you would connect to the computer next to you, which is connected to the same router/switch/whatever, it uses all ICE's and determine the shortest, and that is directly through that point. That your collegue got less ICE candidates has to do with the ammount of devices it has to go through.

Please note that every network adapter inside your computer which has an IP adress (I have a vEthernet switch from hyper-v) it also creates an ICE for it.

Skippet

Do you send ICE's or candidates? Isn't ICE just the name of the method (protocol) for which candidates are gathered? – Slender

@Slender this answer was written a long time ago, back when my English was worse than it is now. I never expected this "by the way, from looking at ICE candidates I can see this" type of answer to get so many upvotes (it's by far my most upvoted answer). I should update the wording and writing, but to answer your question: yes, ICE is the abbreviation of the protocol, the things you send are ICE candidates. – Skippet

Perhaps the answerer misunderstands what an ICE candidate is. What does he mean by 'all the nodes'? Is he suggesting ICE is used in a shortest path algorithm to find the optimal path between initiating and responding peer? – Yellowwood

Answer 2

ICE stands for Interactive Connectivity Establishment , its a techniques used in NAT( network address translator ) for establishing communication for VOIP, peer-peer, instant-messaging, and other kind of interactive media.

Typically ice candidate provides the information about the ipaddress and port from where the data is going to be exchanged.

It's format is something like follows

a=candidate:1 1 UDP 2130706431 192.168.1.102 1816 typ host

here UDP specifies the protocol to be used, the typ host specifies which type of ice candidates it is, host means the candidates is generated within the firewall. If you use wireshark to monitor the traffic then you can see the ports that are used for data transfer are same as the one present in ice-candidates.

Another type is relay , which denotes this candidates can be used when communication is to be done outside the firewall.

It may contain more information depending on browser you are using. Many time i have seen 8-12 ice-candidates are generated by browser.

Concessionaire

But why do I get so much candidates and why do I have to exchange them with the other peer? – Grumous

The ICE protocol won't contain data about the browser... That is where SDP (Session Description Protocol) is for (and also for sharing what kind of data the RTC is going to be used for, eg audio, video, codec's etc) – Skippet

When building a WebRTC connection, how do I choose between ice candidates? I've got eight options or so (in my dev environment). Some carry out audio, some lose video. It's really strange : ) – September

As i mentioned above about various type of ice candidates , ideally you should handle all ice candidates, you just provide all the ice candidates to the webrtc ,webrtc will do rest work. – Concessionaire

Can we cache them for a session. Let say if a person is making multiple calls in same on android. What kind of cache deletion policy should we follow? Should we clear the cache on network change (type as well as connectivity). – Aristotelian

I found local rtcPeerconnection has two candidates, one is udp, the other is tcp, can I disable the tcp candidate? Becasue I don't want tcp transport, only udp, even udp is not woking, I wanna it to be failed, not switch to tcp. @IchigoKurosaki – Yak

Answer 3

Ichigo has a good answer, but doesn't emphasise how each candidate is used. I think MarijnS95's answer is plain wrong:

Every ICE contains 'a node' of your network, until it has reached the outside

By providing all nodes, the RTC connection finds the shortest route itself.

First, he means ICE candidate, but that part is fine. Maybe I'm misinterpreting him, but by saying 'until it has reached the outside', he makes it seem like a client (the initiating peer) is the inner most layer of an onion, and suggests the ICE candidate helps you peel the layers until you get to the 'internet', where can get to the responding peer, perhaps peeling another onion to get to it. This is just not true. If an initiating peer fails to reach a responding peer through the transport address, it discards this candidate and will try a different candidate. It does not store any nodes anywhere in the candidate. The ICE candidates are generated before any communication with the responding peer. An ice candidate does not help you peel the proverbial NAT onion. Also regarding the second quote I made from his answer, he makes it seem like ICE is used in a shortest path algorithm, where 'shortest' does not show up in the ICE RFC at all.

---

From RFC8445 terminology list:

ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can establish a data session.

The purpose of ICE is to discover which pairs of addresses will work. The way that ICE does this is to systematically try all possible pairs (in a carefully sorted order) until it finds one or more that work.

Candidate, Candidate Information: A transport address that is a potential point of contact for receipt of data. Candidates also have properties -- their type (server reflexive, relayed, or host), priority, foundation, and base.

Transport Address: The combination of an IP address and the transport protocol (such as UDP or TCP) port.

---

So there you have it, (ICE) Candidate was defined (an IP address and port that could potentially be an address that receives data, which might not work), and the selection process was explained (the first transport address pair that works). Note, it is not a list of nodes or onion peels.

Different users may have different ice candidates because of the process of "gathering candidates". There are different types of candidates, and some are obtained from the local interface. If you have an extra virtual interface on your device, then an extra ICE will be generated (I did not test this!). If you want to know how ICE candidates are 'gathered', read the 2.1. Gathering Candidates

Yellowwood

Answer 4

I know this is long forgotten. However, in the year 2023, I have been playing with RPi, aiortc, FastAPI, websockets, and Remote.it for one-way streaming my DIY security camera in my home to my phone. Even with ChatGPT, it was very difficult to actually figure this out. Fortunately, I believe I made a personal breakthrough understanding how these work. RTC Ice Candidates are, so far, essential for my the Peer connection to make a proper connection to my RPi when on different networks.

Steerage