Re: [MMUSIC] Trickle ICE

[Martin Thomson <[e-mail]>]

Forgot something, inline below...

On 11 October 2012 10:13, Martin Thomson <[e-mail]> wrote:
> 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?

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.


>> 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 ;)