Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Christer,

(one minor comment)

On 12.10.12, 20:04, Christer Holmberg wrote:
>>>> All in all, making assumptions on the receiving end is always a
>>>> risk. If the host sending the candidates knows that they are its
>>>> best/only candidates, then it could indicated so by sending the
>>>> end-of-candidates message we describe in the draft.
>>>
>>> In case Bob has a public IP address, why does Alice need to send an
>>> offer with the additional candidates in the first place? Why not
>>> simply start using them, and Bob will process them as peer reflexive
>>> candidates?
>>>
>>> (I can understand that signaling is needed in case per-candidate
>>> ufag/pwd values are used, but let's assume a case where the same
>>> values are used for all candidates.)
>>
>> My point was that Bobs IP address being public:
>>
>> * does not mean it is the best option: VPN, tunnelling, and multiple
>> interfaces can all generate public host IP addresses that are a lot less
>> preferable to server reflexive ones.
>> * does not even guarantee that it's reachable. Connectivity may be
>> administratively prohibited, routes can be down.
> 
> Alice CAN continue to gather candidates, in case there are better
> ones. My question was why she needs to signal them to Bob in a new
> offer, instead of simply start sending STUN checks associated with the
> candidates? Bob will then process them as peer reflexive candidates.

She can do that of course. And she should. That's what trickling is
about after all. But those checks may fail for the reasons above (second
bullet) or simply because Bob has a firewall with endpoint-dependent
filtering so it won't let Alice's packets come in unless Bob also starts
sending packets to her.

Does this make sense?

Emil

-- 
https://jitsi.org