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

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Sep 2011 22:33:24 +0200

Hi, I expect this topic has already been addressed in this maillist.
But it not, I would like to comment that ICE does not work when both
peers are behind symmetric NAT (very common in home routers).

In that case, the only solution is to use TURN by adding it the last
candidate in the ICE SDP, but TURN requires authentication and, of
course, a TURN server.

Has been this topic discussed? If the website supposed to provide the
WebRTC client with information about which TURN server to use and
username:password for using it?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sat, 24 Sep 2011 23:12:49 +0200

> username:password for using it?

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

the TURN server credentials should be provisioned by the service provider

/alfred

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Sep 2011 23:15:08 +0200

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

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 25 Sep 2011 12:51:25 +0200

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

---

From: Roman Shpount <[email-masked]>
Date: Sun, 25 Sep 2011 17:05:30 -0400

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 <[email-masked]>wrote:

> 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.
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 25 Sep 2011 14:36:20 -0700

> and never proxy media. Finally we need to specify credentials to use with

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

>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 25 Sep 2011 18:38:31 -0400

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 <[email-masked]> wrote:

> > On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand <[email-masked]
> >
> > wrote:
> >>
> on
> right