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

Roman Shpount <> Sun, 25 September 2011 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A257A21F8797 for <>; Sun, 25 Sep 2011 14:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TpDu-8vPFBcQ for <>; Sun, 25 Sep 2011 14:02:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF31521F84C1 for <>; Sun, 25 Sep 2011 14:02:52 -0700 (PDT)
Received: by gwj15 with SMTP id 15so4942093gwj.31 for <>; Sun, 25 Sep 2011 14:05:33 -0700 (PDT)
Received: by with SMTP id n3mr5481217ybe.397.1316984733511; Sun, 25 Sep 2011 14:05:33 -0700 (PDT)
Received: from ( []) by with ESMTPS id q16sm1948442ybf.23.2011. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Sep 2011 14:05:33 -0700 (PDT)
Received: by ywa6 with SMTP id 6so4811853ywa.31 for <>; Sun, 25 Sep 2011 14:05:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id r2mr25072694pbi.71.1316984731069; Sun, 25 Sep 2011 14:05:31 -0700 (PDT)
Received: by with HTTP; Sun, 25 Sep 2011 14:05:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 25 Sep 2011 17:05:30 -0400
Message-ID: <>
From: Roman Shpount <>
To: Harald Alvestrand <>
Content-Type: multipart/alternative; boundary="bcaec520f6111203f404adca67d5"
Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Sep 2011 21:02:53 -0000

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.

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

> On 09/24/2011 11:15 PM, Iñaki Baz Castillo wrote:
>> 2011/9/24 Alfred E. Heggestad<>:
>>> "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