Re: [MMUSIC] Trickle, privacy and bogus addresses

On 14.03.13, 16:10, Adam Roach wrote:
> If we can maintain privacy without having to specify an intentionally 
> bogus address, then I am strongly in support of avoiding this silliness 
> also.

We do not need a bogus candidate because of privacy. We have one that is
defined by 3264 with exactly the necessary meaning: 0.0.0.0.

The reason we need a bogus candidate is because some people here have
expressed concerns that we need to take into account poorly
implemented/legacy SDP parsers who might somehow fail on 0.0.0.0 because
of what it used to mean in 2543.

Emil

> 
> /a
> 
> On 3/14/13 16:00, Martin Thomson wrote:
>> Someone proposed that we use 0.0.0.1:9 to signal "no candidates".
>>
>> I don't believe this to be necessary and would rather we don't go there at all.
>>
>> If privacy concerns do not prevent the sharing of addressing
>> information, trickle can proceed with host candidates.  This is not a
>> real concern.
>>
>> If privacy protection is paramount, pay the price and allocate a turn
>> candidate prior to sending the offer or answer.  It's only the caller
>> that is required to pay this cost, which is a little silly because the
>> answerer is the most likely to want this sort of protection.
>>
>> Furthermore, in WebRTC, we have a candidate pool that would ensure
>> that would allow us to prime the answerer in preparation for receiving
>> an offer such that overall session setup would not take any longer.
>> If anyone is unconvinced, I'm happy to walk through a proof of this.
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org