W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2012

Re: Feedback on the PeerConnection API

From: Roman Shpount <roman@telurix.com>
Date: Mon, 16 Jul 2012 20:13:54 -0400
Message-ID: <CAD5OKxub8v9FdGhHvi-0eMbF1hhU524SSnJiXsGx=0QLyQ=gVw@mail.gmail.com>
To: Li Li <Li.NJ.Li@huawei.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, "ekr@rtfm.com" <ekr@rtfm.com>
"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****
>
>  ****
>
Received on Tuesday, 17 July 2012 00:14:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC