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

Cameron Byrne <cb.list6@gmail.com> Sun, 25 September 2011 21:33 UTC

Return-Path: <cb.list6@gmail.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 451DC21F8B28 for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 14:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level:
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 zXmHj-yTDxsG for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 14:33:41 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4C21F8B27 for <rtcweb@ietf.org>; Sun, 25 Sep 2011 14:33:41 -0700 (PDT)
Received: by gyd12 with SMTP id 12so4654987gyd.31 for <rtcweb@ietf.org>; Sun, 25 Sep 2011 14:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RN2JqYmhdXSCyKgiNngbqj2XfqDVtXI88861Nb/nbuo=; b=AxJyNIOcfEK/QsvZB5nhvsqf+kcvJztDSK/0kuHFuJJhRff6tR/xp37NGGw02+iORK 3PdaL1m1BCaYtxExPmuK4PabeGK9l03rqbybZNv3b6QKMfkqlY5Rlxue5z5UfLdyl3Hj ex13I0kyIxgpav0mGjDYGuWMw+d1c6yEp6CmQ=
MIME-Version: 1.0
Received: by 10.68.15.194 with SMTP id z2mr25118847pbc.47.1316986580492; Sun, 25 Sep 2011 14:36:20 -0700 (PDT)
Received: by 10.142.89.1 with HTTP; Sun, 25 Sep 2011 14:36:20 -0700 (PDT)
In-Reply-To: <CAD5OKxvUL9_xvFoxiOuknAaozdW8DF4u4CfFrrby+T7QCCLUEA@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>
Date: Sun, 25 Sep 2011 14:36:20 -0700
Message-ID: <CAD6AjGTQOb+KKcso__sCtzpSB1uKFpjaDjBRd9piK+qhdZrcXQ@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 21:33:42 -0000

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