Jiri Kuthan wrote:
At 10:48 PM 12/2/2003, Olle E. Johansson wrote:
Jiri Kuthan wrote:
at best both, STUN does not help with all kinds of NATs. Use STUN if you can, RTP proxy otherwise. -jiri
You can't choose between the fruit basket and an apple...
I'm not good in agronomy so I can't compete in statements about fruits, apples and other healthy food.
I didn't involve tofu :-)
However as for NATs, the strategy "use STUN by default, rtp relay as last resort" works pretty well. STUN actually does the magic to let your calls through for many NATs.
Your right, but for documentation I should say "use STUN discovery to make the client behave correct for your network. If it doesn't work out, use a RTP relay".
Or have I missed something in regards to STUN? STUN, TURN, COMEDIA - I wish we didn't have NAT's... IPv6 - a glory new world.
/O ;-)
-jiri
STUN checks the NAT situation from a client point of view. STUN does not do magic to let your calls through, it gives the UA an idea on how the world looks and then the UA makes the choice on how to get traffic going or give up and eat up all the fruits in the basket.
If you have problems with your NAT, the RTP proxy might be part of the solution to get calls going in combination with SER module Nathelper. The whole idea is to take care of the media stream when the two SIP clients can't handle the media stream across the NAT's. Yes, it shouldn't be necessary.
Other solutions involve symmetric RTP, see http://www.voip-info.org/wiki-RTP+Symmetric
More info on STUN: http://www.voip-info.org/tiki-index.php?page=Stun
Vovida.org have an Open Source STUN server. Pointer here: http://www.voip-info.org/tiki-index.php?page=Open%20Source%20Voip%20software
Disclaimer: This is a messy area. I could be all wrong... :-)
/Olle
-- Jiri Kuthan http://iptel.org/~jiri/