Re: [rtcweb] Filling in details on "trickle ICE"

[Emil Ivov <[e-mail]>]

On 28.08.12, 00:29, Bernard Aboba wrote:
> Emil Ivov said: 
> 
>> Well an ICE stack that implements trickle as per XEP-0176 would currently
>> not interoperate with a 5245 implementation or, at best, would lead to
>> unpredictable results.
>> 
>> The description in XEP-0176 is actually quite perfunctory and can't really
>> be considered a proper specification.
>> 
>> A document that describes a proper way of implementing this would hence be
>> quite helpful.
> 
> [BA]  You are correct that XMPP/Jingle signaling will not be understood by a
> SIP UA. 

Right. And of course, I was not referring to signalling.

> However,   I don't see anything inherent in the use of STUN/TURN 
> within XEP-0176 that violates RFC 5245. 

It's more about ICE processing rather than STUN and TURN and the fact
that, if an ICE implementation is not prepared to handle trickling it
would not work well with one that does. (more below)

>From your other mail:

> Details of the updated offer are described in RFC 5245 Section 9.1.2.2:

I am not sure how 9.1.2.2 would apply here given that it's about sending
updated offers once ICE has completed. It even says that:

    The agent MUST include candidate attributes for candidates matching
    the default destination for each component of the media stream, and
    MUST NOT include any other candidates.

Did you instead mean to quote section 9.1.2.1 which contains the following:

   The agent
   MAY include additional candidates it did not offer previously, but
   which it has gathered since the last offer/answer exchange, including
   peer reflexive candidates.

9.1.2.1 does indeed refer to updating ICE for "Existing Media Streams
with ICE Running".

While I agree that this does look like trickling I am not sure it was
intended to be used in exactly the same way that we are discussing here
and the text is not enough to cover a proper trickling implementation.

The main issue is that there's currently nothing in 5245 that would
allow an agent to determine if more candidates are to be expected. If
trickling is in use there's no way for a controlled agent to know that
(or if) more candidates are to be expected. This creates a race
condition which may result in the controlled agent moving into the "ICE
Failed" state before it has received all candidates from the controlling
agent.

Such premature failures can happen very easily if the first offer only
contains addresses that can be determined as unusable without even
running any checks. This would be the case for an IPv4-only host
receiving an offer with IPv6 candidates only (and vice versa). One can
probably come up with a few more cases like this one.

> If the issue is lack of clarity in
> XEP-0176, shouldn't that be brought up in the XSF, which owns the
> specification?

Nope, XEP-0176 would be crystal clear if the IETF comes up with a
document that explains how ICE agents should behave in situations where
addresses continue to arrive after the original offer.

Emil

--
https://jitsi.org