Re: Feedback on the PeerConnection API

"none" is there for the case where you want to completely defer ICE
processing for some reason, perhaps you don't even want to give out relay
candidates to the other side until the callee accepts the call.

I thought about adding a "local" option, but I couldn't ever come up with a
use case for it.


On Mon, Sep 3, 2012 at 7:46 AM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> The reason "none" was in there was to not leak IP address information - so
> I don't think "none" can mean local.  When set to "none", you really are
> stopping all traffic to the other side. So to answer Li's original question
> - "Yes". If people wanted to add "local" to the list, that would probably
> be fine if there was a good reason to have it.
>
>
>
> On Jul 16, 2012, at 6:13 PM, Roman Shpount <roman@telurix.com> wrote:
>
> > "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
> >
> >
> >
> >
>
>
>