Subject: [midcom] Truncated STUN test

From: "Pete Cordell" <[email-masked]>
Date: Wed, 3 Apr 2002 11:42:17 +0100

Jonathan,

My understanding is that only NATs that exhibit cone NAT functionality
(which presumably includes 1-to-1 NAT) are useful for things like SIP.  For
clients that are only interested in whether they can run VoIP (or something
similar) knowing the various types of NAT is not really required.  All they
want is a go/no go decision on whether they can communicate through the NAT.

If that's the case it would be worth specifying a truncated STUN test
sequence that yields only this go/no go decision.

That would seem to involve doing Test I on the set of SRV derived STUN
servers until one is found that works.  You would then do a Test II.  Once
you have the result of that test, you can stop.

Either this could be mentioned as a separate test sequence, or the current
text could be amended to say something like:

"If the client requires cone NAT functionality to operate (such as for SIP
RTP/RTCP) and is not interested in discovering the particular restrictions
of a NAT that is not useable, it can stop the testing at this point.

If it wishes to know the restricted type of NAT, the following tests can be
performed...."

Thanks,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Apr 2002 13:44:40 -0500

Pete Cordell wrote:
> (which presumably includes 1-to-1 NAT) are useful for things like SIP.

Thats not the case. Cone NATs are ideal, but it is possible to use SIP
along with stun and get voip working when you have an restricted cone
nat too. You'll need to prime the nat with "suicide" packets to open
holes for the media from the peer. This is documented in
draft-rosenberg-sipping-nat-scenarios-00.txt, page 13.

> For

Fair enough.

> you have the result of that test, you can stop.

Since it does work behind a restricted cone nat, you actually need to
run the full sequence in any case, as far as I can tell.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 4 Apr 2002 19:24:59 -0800

The open source implementation of STUN at
http://www.polyphase.ca/software/stun/overview.html
runs all the tests in parallel with the exception of the 4th test that
happens once a result to the 1st test is done.

You can look at the code to see the details but the point is that it finds
out what type of NAT it is in similar time to what it takes to find out if
you are behind a NAT at all. I think this approach illustrates that go/no go
probably has a similar burden to compute as finding all the stuff described
in the STUN draft. The parallel approach may eliminate the need to optimize
something else.

A related thing I have seen come up has to do with getting consecutive ports
with the right even odd combination for RTP/RTCP. Some antidotal experiments
suggested there were no problems with an approach of doing several
simultaneous parallel request then looking at the results and using the
mapped ports that have the right properties.

Cullen

PS. I just noticed that Jonathan seems to have a track record of protocols
with interesting names when spelled in reverse.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, April 04, 2002 10:45 AM
> To: Pete Cordell
> Cc: [email-masked]
> Subject: [midcom] Re: Truncated STUN test
>
>
>
>
> Pete Cordell wrote:
> >
> > Jonathan,
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Apr 2002 23:19:20 -0500

> in the STUN draft. The parallel approach may eliminate the need to

More importantly, we don't need to specify that you should or shouldn't
do it in parallel, and we don't need to specify whether you do fewer
tests or more tests. The protocol itself is a simple request/response
exchage with a dumb server. The ways in which a client can use the
protocol to learn different things need not be standardized, and don't
require the server to know what you want the client wants to do.

> mapped ports that have the right properties.

Really? It would only work for nats that are allocating ports
sequentially. I wonder how often that is the case. 

> with interesting names when spelled in reverse.

I never even noticed that - honest! Its like those records, where, if
you manually played them backwards, you could supposedly hear hidden
messages, from, well, you know... I don't know what this says about me.
Hmm.

-Jonathan R.