<div dir="ltr">Hi everybody,<div><br></div><div>I'm using libnice in an open source WebRTC gateway I've published recently, called Janus (<a href="https://github.com/meetecho/janus-gateway">https://github.com/meetecho/janus-gateway</a>) and it has worked great so far!</div>
<div><br></div><div><br></div><div>In the latest few days I've started studying how to implement Trickle ICE, though, and I'm a bit stuck. I guess you already know what Trickle ICE is, but if you don't, it's basically a recent proposal (<a href="http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01">http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01</a>), especially conceived (at least in the beginning) for WebRTC, to speed up the ICE process. The idea is not to wait for all the candidates to be gathered to send your SDP, but to first send a candidates-less SDP, and then send one by one (trickle) each candidate as soon as you're able to gather it.</div>
<div><br></div><div>Ideally, this should be able to speed up the whole ICE process, as you may find a suitable pair before your last candidate has been gathered. In the worst case scenario, it's as slow as regular ICE.</div>
<div><br></div><div><br></div><div>The problem with this, though (and here comes why I'm posting here), is that it's not backwards compatible, or at least not 100%, with regular ICE. Specifically, as explained in Section 3 of the current specification (<a href="http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-3">http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-3</a>), the main problem is that having just a few candidate pairs to check time after time could easily empty the current list of candidates an agent is aware of, thus leading to a failure in the ICE process. For instance, you get a local candidate, send that one to your legacy-ICE peer using an out-of-band channel, and while you're gathering one more candidate to send later on, the validation and pairing of the candidate you've just sent has already been failed by the peer: since the peer is only aware of that single candidate, and there's no other candidate to try in the list, for what the peer is concerned ICE just failed.</div>
<div><br></div><div>Since I'm trying to understand how I can make use of libnice to implement trickle in my gateway nevertheless, do you think there's any trick one could use for the purpose, without needing support for trickling to be added to the library itself? I was thinking especially of some ways to "delay" the failure of the pairing of some candidates, for instance, so that to allow further candidates coming later to arrive before the whole process for the agent fails. In general, I've noticed libnice does not fail right away when no pair can be found, but that some seconds pass, probably to take into account timeouts and the like, but since that may not be sistematic (or is it?) I'm not sure that could be depended on for trickling scenarios.</div>
<div><br></div><div><br></div><div>Do you have any suggestion on how this could be achieved? Are there plans to include support for actual Trickle in the library in the future, by the way?</div><div><br></div><div>Thanks!</div>
<div>Lorenzo</div></div>