RE: Feedback on the PeerConnection API

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

Received on Monday, 16 July 2012 22:07:28 UTC