[MMUSIC] Trickle ICE and frozen candidates

[Emil Ivov <[e-mail]>]

Hey all,

In Orlando we discussed a few issues around trickle ICE without reaching 
any form of consensus so it would be great if we could do so here.

The most delicate is about handling frozen candidates with trickle ICE. 
I apologise for the long e-mail that's about to follow. It's just one of 
those gluey, hairy issues. The faster we get rid of it, the better, so 
please don't be intimidated by the text ;).

With vanilla ICE, we have the advantage of knowing that candidate pairs 
will be ordered the same way on both sides. Checks are executed in the 
same order, which allows NATs to open all the necessary holes in their 
filters.

The "frozen candidates" algorithm relies on this. It starts by 
unfreezing, on both sides, all the first pairs for all foundations. In 
other words, for an audio/video rtp/rtcp call, we normally start ICE 
processing with Audio.RTP and then unfreeze RTCP and Video when the 
first checks have succeeded (roughly put).

The problem with trickle ICE is that such an order is no longer 
guaranteed. It is hence possible that both agents obtain their STUN 
candidates in different order. For example, one of them first obtains 
Audio.RTP, while the other one first learns a mapping for Video RTCP.

Here's a more specific example: Imagine Alice and Bob both have a single 
host address each: A1 and B1 (both are NATed in different LANs). They 
both use ports 5000/5001 for Audio RTP/RTCP and ports 5002/5004 for 
Video RTP/RTCP.  They also both use a STUN server (no TURN for simplicity).

Now let's say that Alice gets (and trickles) a STUN candidate for her 
Audio.RTP base, while Bob first obtains one for RTCP.

For clarity, their check lists would hence look something like this:

Foundation:  A1B1	       A1B2	        A2B1	
Audio.RTP    A1:5000/B1:5000                    A2:5000/B1:5000	
Audio.RTCP   A1:5001/B1:5001   A1:5001/B2:5001		
				
Video.RTP    A1:5002/B1:5002			
Video.RTCP   A1:5003/B1:5003			

We now arrive at the essence: If we are to use freezing in a way that's 
similar to 5245, then Alice and Bob would both unfreeze the first pair 
they have for a given foundation and keep everyone else frozen: Alice 
will thus be sending STUN checks to Bob for Audio.RTCP, while Bob tries 
to conn. check Alice's Audio.RTP candidate.

While they do this, they will learn and trickle all the other candidates 
for these foundations but this wouldn't matter as they would have to 
remain frozen.

Both of the above checks and their entire foundations will hence fail 
since they won't be symmetric.

I hope the description makes sense.

So we basically have two ways to go about this:

1. Try to come up with some rules that avoid or fix the above situation. 
We could try to formulate text that basically starts the unfreezing only 
once we have symmetric candidates for all foundations.

2. We could start by unfreezing the first available pair for any 
foundation and then also unfreeze new pairs with a higher priority. New 
pairs with a lower priority will remain frozen until at least one higher 
priority pair succeeds.

3. We could also get rid of freezing and just start checks for anything 
we get. STUN transactions give us quite some leash in terms of time so 
that even if one of the peers starts checks for a given component 
earlier than the other, this should not be reason enough for failure. 
(Although it could lead to delays in some cases).

While 1 and especially 2 may be preferable in terms of efficiency, 
personally, I am worried that getting it right in terms of spec and 
implementation is non-trivial and this may become a common reason for 
interoperability problems. Therefore, 3 does seem like the simplest way 
to go.

Opinions?

Cheers,
Emil

-- 
https://jitsi.org