Subject: [rtcweb] STUN vs TURN questions

From: cowwoc <[email-masked]>
Date: Thu, 22 May 2014 14:49:13 -0400

Hi,

Which mailing list is appropriate for asking high-level questions 
regarding the STUN, TURN protocols?

I read online that STUN is expected to be successful in 90-95% of cases 
but (unless I misunderstood something) the most popular selling router 
brands ships with symmetric NAT. I just want to understand why my 
connections are falling back to TURN for most/all cases. One test I ran 
recently was connecting Asus RT-N66U with the same kind of router, and 
one cases where the Asus RT-N66U was connected to another router (whose 
brand I don't remember). How do I find out the type of NAT supported by 
a given router?

It would be nice if the browser or TURN server was logging the kind of 
NAT detected. Do they?

Thanks,
Gili

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 May 2014 14:15:18 -0500

> regarding the STUN, TURN protocols? 

TRAM

> (unless I misunderstood something) the most popular selling router 
> brands ships with symmetric NAT.

http://tools.ietf.org/html/draft-jennings-behave-test-results-04#section-4

/a

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 May 2014 16:49:58 -0400

> http://tools.ietf.org/html/draft-jennings-behave-test-results-04#section-4 

I'm afraid that's a weeee bit out of date (document 2008, routers from 
2004).

I hope someone has done a more recent survey or (hint hint) put up a 
database site where people can annotate (and a tool to test).  This has 
been done for "how do I port-forward on my router" in the past.

It does get tricky since some routers may be full-cone if there isn't a 
collision, then symmetric if they're forced onto another port, and even 
far more odd weirdnesses (Cullen can give chapter and verse I believe).  
That said, so many of them share common underpinnings (especially now) 
that there's a lot of commonality.

Without universal TURN (and generally better than TURN when used) 
port-forwarding can avoid the delay/etc that results from TURN. This 
requires ability to restrict the port allocations used for webrtc (and 
when used locks out other devices in the house, or requires you to 
configure each for a different port range), and other related problems.  
Having an advanced config in the browser (not in the JS app/etc) for 
limiting port allocation ranges probably makes sense.

There are other tricks (each with issues), but using many of them 
requires exposing the traffic details (i.e. what it is) to the router, 
which might or might not make sense.  (Port-triggering, etc).  Many of 
these are based on the router being able to infer that a 
call/communications-channel is being set up and triggering temporary 
forwards, and that is antithetical to keeping the signaling/etc secure.  
That doesn't mean the browser couldn't cooperate with the router to get 
mappings (pcp - bug 845007, UPnP (oh my), etc).

Sigh

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Dan Wing <[email-masked]>
Date: Thu, 22 May 2014 17:49:17 -0700

On May 22, 2014, at 11:49 AM, cowwoc <[email-masked]> wrote:

> Hi,
> 
> Which mailing list is appropriate for asking high-level questions regarding the STUN, TURN protocols?
> 
> I read online that STUN is expected to be successful in 90-95% of cases but (unless I misunderstood something) the most popular selling router brands ships with symmetric NAT. I just want to understand why my connections are falling back to TURN for most/all cases.

TURN is only necessary when *both* peers are behind an endpoint-depending mapping NAT, or UDP is filtered (such that TURN or TURN-TCP is outright necessary).  The only published statistic I have found is https://developers.google.com/talk/libjingle/important_concepts which says a direct (non-TURN) path can be achieved 92% of the time, but that statistic is old.

> One test I ran recently was connecting Asus RT-N66U with the same kind of router, and one cases where the Asus RT-N66U was connected to another router (whose brand I don't remember). How do I find out the type of NAT supported by a given router?
> 
> It would be nice if the browser or TURN server was logging the kind of NAT detected. Do they?

But it can't be done properly.  There isn't a "type", as Randell mentioned.  The type can vary under load and can vary when another internal host wants to use the same port, can change if the port is allocated by management system (UPnP IGD or GUI), and other factors.  It just doesn't work well.  That is why ICE abandoned trying to profile "what kind of NAT is present" and just tries everything, because that gives best chance for success.

There was a NAT testing tool that Microsoft released which attempted to classify the NAT, but didn't take into account all of the nuance with load, port conflicts, etc.  It was announced at http://www.ietf.org/mail-archive/web/behave/current/msg02117.html but the URL cited in that post now returns a 404.

Another place to ask is BEHAVE, which is the working group that standardized STUN and TURN.  The working group is closed but its mailing list is still open.

-d

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 26 May 2014 11:28:55 +0000

>> I read online that STUN is expected to be successful in 90-95% of cases but (unless I misunderstood something) the most popular selling router brands ships with symmetric NAT. I just want to under…
Are you doing ICE? STUN alone is not necessarily sufficient to do get media flowing through your local NAT and the remote NAT. For that to work you need ICE that punch holes in the NATs in a synchronised way to maximise the chances of success. 

> TURN is only necessary when *both* peers are behind an endpoint-depending mapping NAT, or UDP is filtered (such that TURN or TURN-TCP is outright necessary).  The only published statistic I have fo…
For solutions with lots of enterprise networks I have seen numbers in the lower half of 80%. But either way the numbers are to large to ignore. Saying that 8% of the calls will not work for a solution is probably not going to cut it. 

> But it can't be done properly.  There isn't a "type", as Randell mentioned.  The type can vary under load and can vary when another internal host wants to use the same port, can change if the port…
We do have two types of NAT. Good NATs and Bad NATs.. :-)

> Another place to ask is BEHAVE, which is the working group that standardized STUN and TURN.  The working group is closed but its mailing list is still open.
And if the problem is ICE you have MMUSIC..

Any historical reasons why the NAT traversal work is spread all over the IETF?

.-.
Pål-Erik

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2014 05:35:32 -0700

On Mon, May 26, 2014 at 4:28 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> connections are falling back to TURN for most/all cases.
> >
> Are you doing ICE? STUN alone is not necessarily sufficient to do get
> media flowing through your local NAT and the remote NAT. For that to work
> you need ICE that punch holes in the NATs in a synchronised way to maximise
> the chances of success.
>
> > TURN is only necessary when *both* peers are behind an
> endpoint-depending mapping NAT, or UDP is filtered (such that TURN or
> TURN-TCP is outright necessary).  The only published statistic I have found
> is https://developers.google.com/talk/libjingle/important_concepts which
> says a direct (non-TURN) path can be achieved 92% of the time, but that
> statistic is old.
> >
> For solutions with lots of enterprise networks I have seen numbers in the
> lower half of 80%. But either way the numbers are to large to ignore.
> Saying that 8% of the calls will not work for a solution is probably not
> going to cut it.
>
> >> One test I ran recently was connecting Asus RT-N66U with the same kind
> of router, and one cases where the Asus RT-N66U was connected to another
> router (whose brand I don't remember). How do I find out the type of NAT
> supported by a given router?
> >>
> > But it can't be done properly.  There isn't a "type", as Randell
> mentioned.  The type can vary under load and can vary when another internal
> host wants to use the same port, can change if the port is allocated by
> management system (UPnP IGD or GUI), and other factors.  It just doesn't
> work well.  That is why ICE abandoned trying to profile "what kind of NAT
> is present" and just tries everything, because that gives best chance for
> success.
> >
> > There was a NAT testing tool that Microsoft released which attempted to
> classify the NAT, but didn't take into account all of the nuance with load,
> port conflicts, etc.  It was announced at
> http://www.ietf.org/mail-archive/web/behave/current/msg02117.html but the
> URL cited in that post now returns a 404.
> >
> > Another place to ask is BEHAVE, which is the working group that
> standardized STUN and TURN.  The working group is closed but its mailing
> list is still open.
> >

That's the way IETF tends to do things. In any case, this discussion is not
appropriate for RTCWEBB.

-Ekr