Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

Hi,

>>>>> 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?

Note that in my use-case Bob has a public IP address, and is an ICE lite entity, so Bob won't send any STUN requests to Alice - only reply to those received from Alice.

Regards,

Christer