Re: [MMUSIC] Trickle ICE

[Martin Thomson <[e-mail]>]

On 10 October 2012 15:46, Emil Ivov <[e-mail]> wrote:
> Yes, the above sentence may indeed be misleadingly read as "respecting
> the order of the streams is all there is to it". What was really meant
> was something along the lines of: "respecting the order of streams
> improves the chances of the connectivity checks being run simultaneously
> for a particular stream/component"
>
>> A naive implementation would use the set of known candidates on each
>> component to make this determination.  However, that set is
>> potentially different to the set of candidates known to their peer.
>> That could cause a mismatch if both peers "unfreeze the first
>> non-empty checklist."
>
> Correct, but this is not going to be a problem. When the corresponding
> candidates eventually find their way to the agent, it would unfreeze
> their local counter-parts and, if necessary, rerun any in-progress or
> failed checks. This is explained in Section 9:
>
>    [snip] the agent examines the check
>    list looking for another pair that would be redundant with the new
>    one.  If such a pair exists and its state is:
>
>    Failed:   the agent chooses the pair with the higher priority local
>       candidate, places it in the Waiting state and removes the other
>       one as redundant.
>    In-Progress:   The agent cancels the in-progress transaction (where
>       cancellation happens as explained in Section 7.2.1.4 of
>       [RFC5245]), then it chooses the pair with the higher priority
>       local candidate, places it in the Waiting state and removes the
>       other one as redundant.
>
> Does this sound reasonable or were you referring to something else?

Actually, this part in Section 9 wasn't very clear.  I think that the
terms aren't quite right.  "Redundant" and "priority" have specific
meanings in ICE that I think aren't quite right for using here.

This wasn't immediately clear, though I get where you are going with
this.  Though I do think that you need to ensure that this
cancellation doesn't occur to the highest priority"

You aren't talking about priority or redundancy, I think.  You want to
ensure that you are making checks on the first component (of the first
media stream).  What you want is probably more like:

The agent examines the check list and looks for a pair with the same
foundation.  Where multiple such pairs exist, the one from the
component that is first in order is selected.  If an existing pair is
selected, based on its state, the following actions are taken:

 Failed:  The agent marks the new pair as Failed.  [[?: not sure that
this is entirely safe, might need to re-open this one to prevent a
race condition...]]
 In-Progress: If the new pair is for a component [[i.e. media stream +
component]] after the existing pair, the new pair is Frozen.  If the
new pair is for a component that comes before the existing pair's
component the existing pair becomes Frozen, the outstanding
transaction on the existing pair is cancelled, and the new pair is
placed in the Waiting state.
  Waiting: If the new pair is for a component [[i.e. media stream +
component]] after the existing pair, the new pair is Frozen.  If the
new pair is for a component that comes before the existing pair's
component the existing pair becomes Frozen and the new pair is placed
in the Waiting state.
 etc...

Does *that* make sense?

> Mmm ... it might be my lack of IETF experience, but aren't references
> supposed to happen the other way around? That is, if RTCWEB decides to
> use Trickle ICE, then shouldn't RTCWEB documents be referring to this
> spec and making whatever normative declarations they find appropriate?

Yes, but the draft makes the claim about a WebRTC app that is
contacting peers in the same domain.  This makes a big assumption:
namely, that ALL the other entities in that domain implement trickle
ICE.  I infer from this that you are assuming that rtcweb is going to
make this MUST implement, so that you can at least expect all browsers
to implement trickle ICE.  That is if you are assuming that the same
domain is only using browsers.

> Besides, trickle ICE is already in use by XMPP apps and SIP will
> probably follow. Why would the RTCWEB usage be referred to and not the
> others?

SIP may well follow, but that doesn't mean that you can make any
assumptions about support.

>> In particular, this relates to the decision to require
>> signaling of support for trickle ICE outside of SDP (a decision that I
>> need to think about a little more).
>
> Well the idea is that it doesn't really need to be signalling. The
> example that we give is about a WebRTC app with no cross domain support.
> In this case the WebRTC app can just enable trickle ICE without checking
> anything since the remote agent is bound to have it too. Again, it's
> just an example. We are not saying this is how it's going to be done for
> RTCWEB.

You can't send an offer sans candidates and expect it to work.  That's
part of the reason you are writing this draft, as I understand.
Unless you know for certain that the other side implements it.  I
don't think that this is realistic.  Therefore, signaling.

> Does this make sense?

Not entirely ;)