|# source : http://code.google.com/p/natvpn/source/browse/trunk/stun_server_list|
|# A list of available STUN server.|
Thanks heaps for this :)
I actually ended up using this list as the source list for a node module (browserify friendly):
From my testing though (I make sure each of the servers is currently responding within 5s) as part of the module unit tests, I ended up removing the following as they either were no longer found in DNS or were just too slow to respond:
Just want to add STUN Servers Located in Japan.
Ref. Source: http://wiki.tomocha.net/SIP_STUNserver.html
Actually, I am thinking about hosting STUN on one of my servers.
Google's recommendations for Hangouts traffic : https://support.google.com/a/answer/1279090?hl=en#latency
Google seems to be broadcasting this IP for stun (188.8.131.52) but it’s no good and does not properly handle STUN requests. It seems to be ISP dependent, meaning certain ISPs are caching that DNS resolution, but I’ve seen the number of Customers across multiple ISPs who are having STUN issues growing this week, and all affected users are resolving stun.l.google.com to the 74.xxx address.
We have implemented a fallback to Freeswitch Stun in case response from Google STUN is not returned. Standard WebRTC protocol in browsers expect on or more STUN server paths and will resolve DNS for both, and will initiate the STUN request to both in parallel for any applicable candidates. This has resolved the issue for us, but would be great if Google can stop broadcasting that IP.
Google apparently provides a pool, but you'll need to reference each individually:
stun.l.google.com has address 184.108.40.206
Note: I can successfully ping them all right now.
You can test a STUN server using the tools on this webpage:
in P2P no necessary use STUN Server, but behind Firewall this connection is stable with this type server, for me STUN Server works is great solution for virtualization behind Firewall Perimetral