RE: Feedback on the PeerConnection API

Roman,

Thanks for the reply. Is "none"="local" a recent proposed change to the spec? As far as I can see, the current webrtc spec and jsep [1] defines "none" as "use no candidates for checking", not as "use only local candidates for checking"

Li

[1] http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-01
Regardless of the configuration, the gathering process collects all
   available candidates, but excluded candidates will not be surfaced in
   onicecallback or used for connectivity checks.


       "iceTransports",  // controls ICE candidates; can be

                         //   "none"  (no candidates)


From: Roman Shpount [mailto:roman@telurix.com]
Sent: Monday, July 16, 2012 8:14 PM
To: Li Li
Cc: public-webrtc@w3.org; ekr@rtfm.com
Subject: 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<mailto: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<mailto:roman@telurix.com>]
Sent: Friday, July 13, 2012 12:44 PM
To: Li Li
Cc: public-webrtc@w3.org<mailto: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<mailto: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