Subject: [midcom] Reference STUN servers?

From: "Justin Uberti" <[email-masked]>
Date: Tue, 18 Nov 2003 13:17:05 -0500

Hello,

I have been testing my STUN client library against the two public STUN 
servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I 
am not getting the results I expect - when I send a binding request to 
the server and get back a CHANGED-ADDRESS, and then send a second 
binding request to the CHANGED-ADDRESS, the servers reply to the binding 
request from a different port (i.e. not the one from the 
CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags.

ex:
sending request to stun01.sipphone.com (69.0.208.27:3478)
received reply from 609.0.208.27:3478
source address = 69.0.208.27:3478
changed address = 69.0.209.22:3479

sending request to 69.0.209.22:3479
received reply from 69.0.209.22:3478 <----------- BAD
source address = 69.0.209.22:3479
changed address = 69.0.209.27:3478

I assume this is not the correct behavior, as it causes the NAT 
detection flow proposed in the STUN RFC to detect port-restricted-cone 
NATs as symmetric NATs. Does anyone know of any running 'reference' 
servers that are known to behave correctly?

Thanks in advance,
Justin Uberti

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Nov 2003 02:34:10 -0500

You are correct that this is not the behavior implied by the 
specification.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Nov 2003 16:45:58 -0800

The best list to get this fixed would probably be email to [email-masked].

Can you send me an ethereal dump with the message you send and the response.
I will see if I can get it fixed on the larry.gloo.net server - I don't
think this should be happening.

Cullen