Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT

Roman Shpount <roman@telurix.com> Sun, 25 September 2011 22:35 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14421F8A6F for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 15:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.826
X-Spam-Level:
X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrLao1ICrM81 for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 15:35:52 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9672F21F8A56 for <rtcweb@ietf.org>; Sun, 25 Sep 2011 15:35:52 -0700 (PDT)
Received: by ywa6 with SMTP id 6so4847430ywa.31 for <rtcweb@ietf.org>; Sun, 25 Sep 2011 15:38:33 -0700 (PDT)
Received: by 10.236.79.197 with SMTP id i45mr35230727yhe.28.1316990313360; Sun, 25 Sep 2011 15:38:33 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id h20sm62960333ani.16.2011.09.25.15.38.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Sep 2011 15:38:32 -0700 (PDT)
Received: by gwj15 with SMTP id 15so4977845gwj.31 for <rtcweb@ietf.org>; Sun, 25 Sep 2011 15:38:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.11.138 with SMTP id q10mr25511066pbb.37.1316990311819; Sun, 25 Sep 2011 15:38:31 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Sun, 25 Sep 2011 15:38:31 -0700 (PDT)
In-Reply-To: <CAD6AjGTQOb+KKcso__sCtzpSB1uKFpjaDjBRd9piK+qhdZrcXQ@mail.gmail.com>
References: <CALiegfnf3=mPAupRtjoqz+fNfxT5V8yivoQB+bgrvAVWp5CVog@mail.gmail.com> <4E7E47D1.9040100@db.org> <CALiegfnY62TZs_=fCzqYqfObB+9yY93v5jfgOjMjtd+oYNgoBA@mail.gmail.com> <4E7F07AD.9030409@alvestrand.no> <CAD5OKxvUL9_xvFoxiOuknAaozdW8DF4u4CfFrrby+T7QCCLUEA@mail.gmail.com> <CAD6AjGTQOb+KKcso__sCtzpSB1uKFpjaDjBRd9piK+qhdZrcXQ@mail.gmail.com>
Date: Sun, 25 Sep 2011 18:38:31 -0400
Message-ID: <CAD5OKxuNJrnfLOTnEv+v8_jkiwSUgms4J1x+5mW0irSvsQx0PQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Cameron Byrne <cb.list6@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec5314ad1b5686704adcbb326
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2011 22:35:53 -0000

What I meant was that RTC client should have TURN support, but should be
able to fallback to use case when only STUN server is available. In real
life TURN server might not always be available to the application developer.
TURN servers for large applications can consume a lot of bandwidth and
typically not offered as a free service. On the other hand, STUN servers a
not resource intensive at all.
_____________
Roman Shpount


On Sun, Sep 25, 2011 at 5:36 PM, Cameron Byrne <cb.list6@gmail.com> wrote:

> On Sun, Sep 25, 2011 at 2:05 PM, Roman Shpount <roman@telurix.com> wrote:
> > It is most likely not right since it assumes that different servers are
> used
> > for STUN and TURN. In real life these are the same server. We also need
> to
> > specify if TURN should be used for this call, or if we plan to use STUN
> only
> > and never proxy media. Finally we need to specify credentials to use with
> > server STUN/TURN.
> >
>
> Not creating a path for proxying media will be a real mistake.  There
> is too much NAT444, ipv6-only, and other complicated CGN work going on
> to not account for this.
>
> That said, TURN with support not only for overcoming NAT44 but also
> NAT64 should be required as defined in RFC 6156
>
> http://tools.ietf.org/html/rfc6156
>
> CB
>
>
> > One more thing that we should decide on is if we need mandate TURNS, or
> if
> > we assume that sRTP security is sufficient and TURNS is only used when
> > connection to TURN server cannot be setup. We also need to figure out how
> we
> > need to interact with proxy configuration of the browser. We can either
> > always use a proxy, use proxy as one of the ICE candidates, only use a
> proxy
> > if direct connection to TURN server is not possible.
> >
> > P.S. We should probably try to get more people with VoIP expertise
> involved
> > on W3C side, since right now it looks like they are underrepresented
> there.
> > _____________
> > Roman Shpount
> >
> >
> > On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand <harald@alvestrand.no
> >
> > wrote:
> >>
> >> On 09/24/2011 11:15 PM, Iñaki Baz Castillo wrote:
> >>>
> >>> 2011/9/24 Alfred E. Heggestad<aeh@db.org>rg>:
> >>>>
> >>>> "ICE does not work" is not correct. ICE will still "work" even if both
> >>>> peers are behind NAT. the media will simply be relayed via a TURN
> >>>> server,
> >>>> and not flow directly between peers.
> >>>
> >>> Yes, that's exactly what I said in my second paragraph :)
> >>>
> >>>
> >>>> the TURN server credentials should be provisioned by the service
> >>>> provider
> >>>
> >>> And is that estandarized within rtcweb?
> >>
> >> so far, the only place where it has been mentioned is in the W3C API
> >> document, which documents how a PeerConnection is initialized with info
> on
> >> TURN / STUN servers.
> >>
> >> I think that part needs attention of a TURN expert; it doesn't look
> right
> >> to me.
> >> But I don't think anything more is needed.
> >>
> >>                Harald
> >>
> >> _______________________________________________
> >> 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
> >
> >
>