Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

Hi,

>>>>> 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.
>
> Oh, I had missed the "Lite" part. Sorry about that.

I may not have made it very clear that I was talking about a "lite" entity, which only provides a host candidate (no matter whether it supports trickle or not)

> So, yes, right now I can't think of a good reason why Alice would continue trickling after a successful check in this case.

Well, Alice can continue to collect local candidates. But, when she has them, she doesn't need to send them to Bob in a new offer - she can simply start using them.

The advantage is that it reduces the need for additional O/A transactions on the wire, which is good, so I think it would be good to document it :)

Regards,

Christer