Re: [MMUSIC] Trickle ICE

[Martin Thomson <[e-mail]>]

Emil,

On 11 October 2012 14:34, Emil Ivov <[e-mail]> wrote:
>> Actually, this part in Section 9 wasn't very clear.
>
> Sorry about that. We'll try to add clarifications before the 01 deadline.

Actually, I think that we've just uncovered a case of talking past
each other.  I was talking about the inter-component interactions and
you were talking about the interactions intra-component.

It's seems obvious to me now that there needs to be more certainty
about the interactions on both axes.

There are clearly interactions on the one component, but I'm not sure
that the conclusions that you have drawn are necessarily optimal.
When you make the choice to cancel an outstanding transaction, you
don't do anything other than increase the probability of success.  The
Binding requests from the lower priority pair have gone out and may
still succeed, assuming of course that both peers are opening
pinholes.

Cancelling the transaction at this point seems counterproductive.
Instead, adding the new pair to the check list such that a transaction
is created in response to the next ordinary check timer pop ensures
that checks proceed on the new pair as soon as is reasonable, while
allowing the lower priority pair to move to the Failed or Succeeded
state normally.

This may result in a lower priority pair reaching Succeeded before the
higher priority one, but that was an inevitable consequence of the
sequencing anyhow.

>> You can't send an offer sans candidates and expect it to work.
>
> Indeed not. I would expect it to fail for non-trickle agents (without
> alerting the remote user) which would then be my cue to fallback to
> vanilla ICE.

That's an interesting choice.  I tend to prefer don't-even-try
solutions to try-fail-and-fallback ones if at all possible.  They tend
to be more robust because your legacy peer doesn't get in a messed up
state due to the failure.

>> Note: we probably also need to note that a transaction can succeed for
>> a Frozen candidate pair (due to the fact that you can't take a STUN
>> packet back, so "cancelling" a transaction might still result in a
>> successful Binding response.  I don't know what you would do with
>> this, but I'd just move the pair to Succeeded.
>
> The case where a cancelled transaction ends up succeeding is indeed
> worth covering, but given how the concept is defined in 5245 then maybe
> at least part of the coverage should go in 5245bis?

5245 doesn't really have the concept of re-freezing a pair, does it?
(Again, this was related to my comments on inter-component checking,
it might not be relevant ultimately.)

Cheers,
Martin