10 comments on “ICE always tastes better when it trickles! (Emil Ivov)

  1. Thanks for such a detailed yet very enjoyable article on one of the most important technicalities of WebRTC! This is indeed going to be a determining factor for the success of Internet communication services from now on. I’ve spent quite some time trying to raise awareness on this in the Telco industry. At the end of the day, trickle vs. non-trickle will make for a handicap factor of 10: in a competition with peer-to-peer web communications (that get trickle for free from the browser), you really don’t want to be on the wrong side of the par!

    The industry doesn’t seem much responsive though…

  2. I just want to say, this is really good ariticle for me to get a overview how the messaging application to get through the NAT to talk with the peer.

  3. Thanks to this article. As far as I understand the difference between RFCed ICE and this is that you make stun request to server while starting negotiation between clients using local interfaces? Almost asyncronically? Why should you do this before the call when you can actually get it on the very beginig of the SIP session (say, registration) and keep this information?

  4. Very educational and well written. Thanks !
    Still cannot get the “half-trickle”.
    If the primary problem was that the three phases happen consecutively, in a blocking way, which may lead to undesirable latency during session establishment.
    (
    three main phases: (1) gathering, (2) candidates are sent to a remote agent and (3) connectivity checks
    )

    And “half-trickle” means: “ that the calling side starts by performing ICE regularly”
    Than we can still fall into undesirable latency from same reasons described in this article
    (e.g. – VPN interface, STUN/TURN server down, wireless interface that appears “up” but is otherwise not connected etc..)

    Can this be clarified how “half trickle” solves this ?

  5. Hey Kamil,

    > As far as I understand the difference between RFCed ICE and this is that you
    > make stun request to server while starting negotiation between clients using
    > local interfaces?

    I didn’t understand the part about “local interfaces” but the rest is pretty much true, with one main difference: it’s not only about STUN. It’s also about TURN and potentially other traversal methods too (e.g. UPnP, Jingle Relay Nodes).

    > Why should you do this before the call when you can actually get it on the
    > very beginig of the SIP session (say, registration) and keep this information?

    There are two main reasons for this:

    1. You don’t know what to reserve until you actually make the call.

    Should a client obtain a binding for 1 port only? That may cut it in case you have a webrtc to webrtc call. You would however need 2 ports in case your a not using bundle (1 for audio and 1 for video) and 4 in case you don’t use rtcp-mux as every stream would require. What happens if you ever need to make a second call? Do you start by pre-binding 8 ports just in case? Or 16? Or maybe 32 to really be on the safe side?

    Now let’s also add TURN here and you get to double all the numbers above once more. Powers of 2 go up pretty quickly. This leads to the second reason which is that:

    2. This would put unbearable strain on TURN and STUN servers. Keeping all these ports alive all the time would imply huge bandwidth requirements on the server side. In the case of TURN, this could mean entire machines that remain unused just so that they would be able to keep ports open.

    So when you take all that into account, pre-allocating and maintaining ports for ICE would probably be more expensive than simply relaying every single call.

    Hope this answers your question!

  6. Hey Rachel,

    You are actually missing something important in your three step process. You should rather have something like this

    (1) offerer gathers candidates and sends offer
    (2) (new) answerer gathers candidates and sends answer
    (3) connectivity checks.

    With vanilla ICE all of them are blocking and strictly consecutive. Full trickle makes them all run in parallel. Half trickle keeps (1) blocking but (2) and (3) still run in parallel.

    Also note that half trickle is only needed in the first Offer/Answer exchange in a session. All consecutive Offer/Answer exchanges (or re-INVITEs for SIP) in that session can use full trickle because support for it would have been confirmed in the beginning.

    Does this answer your question?

  7. Yes and No.
    First, thanks for the detailed answer.
    I want to refer to the first step.
    If it is still blocking (as TURN Server is not replying or Wifi up but not connected) we will still see a delay in the call setup. correct ?
    it is true that without trickle-ice it will be worse, but do you agree that it still can delay the call setup in many seconds ?

Leave a Reply

Your email address will not be published. Required fields are marked *