Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

[Justin Uberti <[e-mail]>]

On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <[e-mail]> wrote:

>
> (Moving this discussion to MMusic.  I suggest further discussion drop the
> tram list, unless it cycles back around to a TURN-specific issue.)
>
> On Jul 29, 2014, at 1:57 PM, Justin Uberti <[e-mail]> wrote:
> >
> > The one thing we need to do is update ICE to allow the CONTROLLING side
> to make dynamic decisions about which pair to use, instead of being forced
> to use PRIORITY (which is what 5245 says). I am going to try to write this
> up before Hawaii.
>
> This is equivalent to using regular nomination, but saying that an
> endpoint can send media on any Confirmed candidate pair, not just the
> Selected one, right?
>

It's a bit more than that - the controlled endpoint has to also synchronize
on the candidate pair, which means that it needs to know what its selected
pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
highest priority nominated pair).

So it becomes:
- controlling side can pick any nominated candidate pair it wants to be its
selected pair
- controlled side should use presence of media from controlling side to
decide selected pair (for secure media), or some TBD attribute (for
non-secure media)
- controlling side can tell controlled side when it is OK to discard
candidate pairs that it has nominated (so that the controlling side can
still safely do the switch to a new pair). This is probably done by having
the controlled side keep all candidates alive that have received a check
from the controlling side in the past XX seconds.

>
> 5245 says that an ICE endpoint MUST be prepared to receive media on any
> candidate, but only sends on the Selected candidate pair.  I don’t know if
> this means, in practice, that ICE-bis could change to the behavior I’ve
> described above and still be backward compatible, or if there’d need to be
> some sort of ice-option negotiation to indicate that this early media (oh,
> dread phrase) is acceptable.
>

Yes, I think we need a new ICE option, or else old ICE impls in the
controlled role will be surprised when they think the selected pair is A
but media arrives on B. We've already seen a number of implementations have
issues with this.