login | register
Sat 17 of May, 2008 [18:28 UTC]

voip-info.org

Navigation
Today's Deals
Recently Visited Pages
Search with Google
Search this site with Google. Results may not include recent changes.
 
Google Ads
Last Changes
Shoutbox
  • Juan Ortega, Thu 15 of May, 2008 [10:33 UTC]: Hi everybody, I'm Juan, an ITCom student, and I need to know what basic elements I need to create a VoIP network. Can anybody helpme, please?,Thank you very much
  • gineta, Wed 14 of May, 2008 [03:58 UTC]: any here not fine the configuration of firewall juniper -screem for VOIP asterisk????
  • Anoop Prabhakaran, Tue 13 of May, 2008 [12:16 UTC]: I am developing Asterisk IVR, Whenever i make a internation call to the IVR system, the DTMF is not getting detected properly, this happens only for the first time, second call onwards system works fine. why this is happening
  • joe, Mon 12 of May, 2008 [04:27 UTC]: Is there an opensource browser based softphone, or a system like Busta where everything is not manages through their website?
  • Nick Barnes, Fri 09 of May, 2008 [11:36 UTC]: Christopher - yesterday I tried an Asterisk install on a CentOS 5.1 box with stock GUI and it all worked fine. Sorry I can't help.
  • aero, Fri 09 of May, 2008 [08:20 UTC]: can someone help me out on this, i tried to play some sound files on my asterisk box and this is the error message i got. WARNING[4429]: format_wav.c:169 check_header: Unexpected freqency 22050 May 8 11:17:39 WARNING[4433]: codec_gsm.c:194 gsmtolin_fra
  • Christopher Faust, Thu 08 of May, 2008 [14:15 UTC]: I beleive that I may have to change something in the xserver configuration. Please advise
  • Christopher Faust, Thu 08 of May, 2008 [14:14 UTC]: Everything was perfect. In the bios I have increased the memory allocated Still receive input not supported on my display.
  • Christopher Faust, Thu 08 of May, 2008 [14:13 UTC]: This would not be my main box. I am doing some testing to see if I can install zaptel and asterisk 1.4 on a full centos 5.1 box with development software Its bizzare, because before I went through the asterisk and zaptel installation everything was perfe
  • Nick Barnes, Thu 08 of May, 2008 [13:44 UTC]: Christopher - I can't see any way in which an Asterisk installation would muck your GUI, but remember that it is advised not to use a GUI on an Asterisk box anyway.
Server Stats
  • Execution time: 0.74s
  • Memory usage: 2.23MB
  • Database queries: 30
  • GZIP: Disabled
  • Server load: 0.79

STUN

STUN (Simple Traversal of UDP through NATs (Network Address Translation)) is a protocol for assisting devices behind a NAT firewall or router with their packet routing.

Note: The STUN RFC states: This protocol is not a cure-all for the problems associated with NAT.


  • STUN enables a device to find out its public IP address and the type of NAT service its sitting behind.
  • STUN operates on TCP and UDP port 3478.
  • STUN is not widely supported by VOIP devices yet.
  • STUN may use DNS SRV records to find STUN servers attached to a domain. The service name is _stun._udp or _stun._tcp

Definitions (from the RFC)

  • STUN Client: A STUN client (also just referred to as a client) is an entity that generates STUN requests. A STUN client can execute on an end system, such as a user's PC, or can run in a network element, such as a conferencing server.
  • STUN Server: A STUN Server (also just referred to as a server) is an entity that receives STUN requests, and sends STUN responses. STUN servers are generally attached to the public Internet.

Various types of NAT (still according to the RFC)
  • Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
  • Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
  • Port Restricted Cone: A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
  • Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.



Closing words (also from the RFC)

14.6 In Closing

The problems with STUN are not design flaws in STUN. The problems in STUN have to do with the lack of standardized behaviors and controls in NATs. The result of this lack of standardization has been a proliferation of devices whose behavior is highly unpredictable, extremely variable, and uncontrollable. STUN does the best it can in such a hostile environment. Ultimately, the solution is to make the environment less hostile, and to introduce controls and standardized behaviors into NAT. However, until such time as that happens, STUN provides a good short term solution given the terrible conditions under which it is forced to operate.





Standard documents

STUN RFC RFC 3489

Update to STUN protocol

STUN standard is currently being reworked in STUN-bis

Software

  • vovida.org has an open source STUN server: vovida.org STUN server
  • a Linux open source STUN server is also available here myStun
  • a Java STUN library (includes a STUN client): JSTUN
  • a Microsoft windows based simple STUN server: miniSipServer
  • PJNATH library from pjsip.org project is an Open Source NAT traversal library supporting STUN, TURN, and ICE.


Public STUN servers


See also


Additional reading

STUN sits along side a number of techniques to achieving NAT traversal, these include TURN, ICE UPnP and Session Border controllers. ICE provides a framework pulls together a number of different techniques: STUN, TURN, RSIP, to allow a client to investigate its environment, however, this flexibility comes at a cost - additional client complexity.

Created by jht2, Last modification by Simon Perreault on Mon 12 of May, 2008 [13:43 UTC]

Comments

Comments Filter

SIP supported STUNs

by KJames_Yulo_De on Tuesday 23 of January, 2007 [15:46:08 UTC]
I heard that major public STUNs have SIP support flaws. But there is one recomended by SIP device manufacturers. That is www.whatismyip.com as well as www.ipchicken.com and www.showmyip.com

AFAIK, www.whatismyip.com supports RFC3489 and can receive and send STUN request from a device. The fact that they can throw you back your publick IP is that they have a STUN at their backend that can automaticaly reply your STUN request. Same as with www.ipchicken.com and www.showmyip.com Many SIP ATA devices today such as ATCOM, xten.de, Chinarobi uses www.whatismyip.com I also heard its SIP friendly.

by trixter on Monday 21 of August, 2006 [00:34:48 UTC]
stun servers really shouldnt be in the telephony application, however client support should be. FreeSwitch supports stun as a client when making calls, which helps get rid of nat related issues. STUN servers are fairly small as well, and easy to install everywhere (or use a SRV record to point to one of the public ones :)

Re: Re: STUN is now widely supported

by sjobeck on Monday 24 of October, 2005 [19:38:00 UTC]
no need to frown. Asterisk is tremendous, you must know that if youre on this site. Please do not try to make Asterisk do everything for all people or it will turn in to a bag of mush. It is tremendous at what it does. STUN is a work-around. As soon as IPv6 is here (hope I'm alive to enjoy it) STUN will be obsoleted. Let others cook-up this stuff & leave Asterisk to do telephone calls. Peace. Love. Linux. Jason

Re: STUN is now widely supported

by Enzo Michelangeli on Friday 26 of August, 2005 [16:08:15 UTC]
Yeah, but not by Asterisk, AFAIK (:frown:) See bounty.

STUN is now widely supported

by oobx on Thursday 25 of August, 2005 [05:02:51 UTC]
I've not seen a SIP device yet that didn't have STUN capabilities. So, I'd argue that the bullet points of STUN (as of 8/25/05) above (" STUN is not widely supported by VOIP devices yet.") is wrong. However, I recommend keeping in mind that some legacy equipment might not support it. If this is the case, try a firmware update.
Edit

sorry

by Anonymous on Wednesday 10 of December, 2003 [10:03:10 UTC]
http://www.sourceforge.net/projects/stun
Edit

stund

by Anonymous on Wednesday 10 of December, 2003 [09:58:41 UTC]
The link to the vovida stun daemon links to what appears to be a deprecated site, it doesn;t appear so at first, but of the code on there, the 0.8 release candidate has no makfiles for unix and the 0.7 release is completely useless in regards to actual stun client in the wild.

It appears that the proper place to get stund from is now http://stun.sourceforge.net

Please update this page with new information, just login and click on the "Edit" or "Add Comment" button above. Get a free login here: Register Thanks! - support@voip-info.org

Page Changes | Comments

Sponsored by:
Terms of Service Privacy Policy
© 2003-2008 VOIP-Info.org LLC

Powered by bitweaver