Re: [rtcweb] Requiring ICE for RTC calls

You can determine that end point is not behind symmetric NAT using older
STUN specification and list discovered IP as a default contact address in
SDP, if you are not behind NAT, you can list the relayed address of the TURN
server as the default address. If you do this, together with the offer that
lists ICE candidates, you would be able to traverse NAT and communicate with
non-ICE end points.

I think discussion in this thread is not whether ICE needs to be supported
or implemented. I would say that ICE without a doubt should be supported. It
is about changing ICE specification as it stands right now, and force the
RTC end point only to communicate with end points that respond with ICE
compliant answer and complete ICE hand shake. This is actually against the
ICE specification as it is defined in RFC 5245, where answerer actually can
refuse to support ICE but still establish a call.
_____________
Roman Shpount

On Mon, Sep 26, 2011 at 2:31 PM, Ravindran Parthasarathi <
pravindran@sonusnet.com> wrote:

> I'm sort of lean towards ICE or ICElite mechanism for NAT traversal of
> media because there is no known better mechanism. In case there is known
> better mechanism, Please list out for discussion.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> >Of Matthew Kaufman
> >Sent: Monday, September 26, 2011 9:19 PM
> >To: Iñaki Baz Castillo
> >Cc: Randell Jesup; rtcweb@ietf.org
> >Subject: Re: [rtcweb] Requiring ICE for RTC calls
> >
> >On 9/26/2011 8:29 AM, Iñaki Baz Castillo wrote:
> >> 2011/9/26 Matthew Kaufman<matthew.kaufman@skype.net>:
> >>> For example, an evil overlord that creates a web site for allowing
> >its
> >>> clients to attack systems behind a firewall could relax those
> >requirements
> >>> and not mandate ICE/SRTP when opening arbitrary connections to
> >systems
> >>> behind said firewall.
> >>>
> >>> The "configuration" must be retrieved by the WebRTC client *from the
> >system
> >>> it will be sending traffic to*... the best format we have for that is
> >to
> >>> send a (rate-limited) STUN connectivity check with short-term
> >credentials
> >>> and see if it is replied to properly. That's how ICE works.
> >> I understand your points and I agree. That would be the perfect
> >scenario.
> >
> >That would be the only scenario that is safe enough to ship in a
> >browser.
> >
> >> But I'm worried about the price to pay for these security constrains
> >> (no interoperability with 95% of SIP-PSTN providers within next 3-5
> >> years).
> >
> >The alternative is that you don't ship anything in the browser, because
> >the browser *cannot* become an attack vector as a result of adding this
> >feature.
> >
> >And "interoperability with SIP-PSTN providers" is only relevant if you
> >are trying to turn the browser into another phone. We have enough
> >phones. What we don't have are new real-time communication experiences
> >that can only be created within this environment.
> >
> >Matthew Kaufman
> >
> >_______________________________________________
> >rtcweb mailing list
> >rtcweb@ietf.org
> >https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>