Re: Feedback on the PeerConnection API

"none" would mean local candidates only, "relay" means relay candidates
only, and "all" means all candidates. Connectivity checks for all generated
and received candidates should always be sent and replied to.
_____________
Roman Shpount


On Mon, Jul 16, 2012 at 6:06 PM, Li Li <Li.NJ.Li@huawei.com> wrote:

>  Thanks for pointing that out.****
>
> ** **
>
> The webrtc draft [1] has this statement:****
>
> ** **
>
> IceTransports ****
>
> This is a enum type constraint that can take the values "none", "relay",
> and "all". The default is a non mandatory "all". ****
>
> This constraints indicates which candidates the ICE engine is restricted
> use. The value "none" means the ICE engine *must* not send or receive any
> packets at this point. The value "relay" indicates the ICE engine *must*only using media relay candidates such as candidates passing through a TURN
> server. This can be used to reduce leakage of IP addresses in certain use
> cases. The value of "all" indicates all values can be used. ****
>
> So if an application creates a PeerConnection and calls updateIce() with
> IceTransport=”none”, would it effectively disable the ICE Agent by
> excluding all its candidates? ****
>
> ** **
>
> Thanks.****
>
> Li****
>
> ** **
>
> [1] http://dev.w3.org/2011/webrtc/editor/webrtc.html****
>
> ** **
>
> ** **
>
> *From:* Roman Shpount [mailto:roman@telurix.com]
> *Sent:* Friday, July 13, 2012 12:44 PM
> *To:* Li Li
> *Cc:* public-webrtc@w3.org
> *Subject:* Re: Feedback on the PeerConnection API****
>
> ** **
>
>
> On Fri, Jul 13, 2012 at 12:36 PM, Li Li <Li.NJ.Li@huawei.com> wrote:****
>
>  > I agree, a way to not use any STUN or TURN server should be specified.*
> ***
>
>  ****
>
> You should be able to just not provide servers.****
>
>  ****
>
> I think we need to distinguish two cases even without any STUN/TURN
> server: 1) do ICE without it; 2) don’t do ICE at all.****
>
>  ****
>
> In case 1), I think the ICE agent will still perform host candidate
> gathering and checking (STUN Bind Request/Response) even without other
> types of candidates found from the servers. ****
>
> In case 2), the ICE agent is disabled and no ICE messages are exchanged
> between peers before RTP – which could be useful if the peer doesn’t
> support ICE.****
>
>  ****
>
> ** **
>
>  ** **
>
> WebRTC clients will not communicate with peers that do not support ICE.
> Please see the previous discussions on this list, but the main reason for
> requiring ICE is to ensure consent from the remote party before sending any
> RTP to it in order to avoid using WebRTC for DOS attacks.****
>
> _____________
> Roman Shpount****
>
>  ****
>