A short conversational explainer defining ICE, Trickle ICE, and ICE-Lite for WebRTC. ICE is described as the process of exchanging and testing network candidates (host, server-reflexive via STUN, and relay via TURN) to establish connectivity. Trickle ICE is an optimization that sends candidates incrementally to reduce connection latency. ICE-Lite is a simplified ICE agent for servers that responds to incoming STUN checks rather than performing full candidate gathering/controlling.
What is the difference between ice, Trickle Ice and Ice Light?
That's a good one. So ICE is basically our whole process of punching holes through nets. And we do that by exchanging candidates and then trying all the addresses in those candidates. Now trickle ICE is a optimization to how we gather these things. Because what ICE traditionally would do is I would gather all the candidates I have, which means my host candidates, my server reflexive candidates from stunt server and my relay candidates from the turn servers. And that would take time, but then I would take them, send them to you. You would start the same process.
Gather madresses, wait for the responses, they might not come. I might retry and gather all the candidates. And then I'm going to start the ICE process. Once I finish that part.
Yes. Meanwhile, I'm totally bored. Okay, so what Trickle is does is I'm like, I gather my host candidates, I send them to you so you have something to do. You can already start checking these candidates. And I get my server reflexes candidate, I send it to you, you already start checking and then finally I get my relay candidates and send them to you as well.
So it's like moving from single threaded to multi threaded because doing things in parallel.
Yes, it's parallelizing. And that means we have a lower connect latency in the end.
And WebRTC for the most part is built based, designed and uses by default trickleize.
Yes. So it uses the optimized version out of the box. And if you want to use non trickle ise, you're basically removing the optimization and you should be very careful about doing that.
Okay. We still have ICE Light.
ICE Light is basically the realization that this whole ISE process doesn't make sense if you're running this on a server, but you need to run it on a server because we need ISE for constant checks. So iseless, basically the dumbed down version of ICE where the browser as intelligent full ICE agent is controlling what the other PLC server does. And it's very simple, you just need to respond to incoming stun messages.
So in a way, with ICE Light, the server is kind of lazy. It wouldn't run the. I'm not going to collect my addresses, Sorry, I'm a server, I either know my public address or I don't care.
Yes.
And then the device that I'm working in front the user, he should be doing all of that crap and sending me the, the candidates that he has and I will just do the ICE work in front of his candidates.
Yes, yes. Even though most of the time for trickle, for ICE Light. You don't need as a server the client's candidates because the client will send you stunt packets, and that way you discover.
Yes.
Where it's coming from.
Okay. And I think it's also important to note that ICE is not a server, but rather a kind of an algorithm that uses Stan and turn servers to do naturversal.
In the end, yes. We made that mistake by calling it ICE Servers. And people get confused a lot about signaling server versus stun server. Make sure to get the terminology right.
Okay, thank you.
Thank you.
Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin
