My opinion about STUN (put it in your book:)
When it works - it really good, save your bandwith and not loading your rtpproxy
But when UAs implementation of STUN client is bad or NAT server is weird and STUN client take wrong decisions it really annoying and because it happening quite often if you offer service to customers with different UAs and NAT routers and providers - we decided not to use it for our company,
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Monday, February 21, 2005 9:22 AM To: Greger V. Teigre Cc: serusers@lists.iptel.org Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply: I won't send a reply for ACK!!
See my inline comments:
On Mon, 21 Feb 2005 15:06:42 +0100, Greger V. Teigre greger@teigre.com wrote:
Java Rockx wrote:
I full agree with you. I see that we've taken different approachs to NAT. We do not use STUN because:
- the two opensource STUN projects are really not written well,no
offense to the authors :)
That is interesting. We use vovida stun and have not experienced any problems at all. What exactly are you referring to?
MyStun is terrible, IMHO, and VOCAL is a dead project, so neither are good choices for our company.
- it adds a new layer of complexity to support
That's true.
- it forces the SIP users to have additional settings on their SIP
phones/UAs
Ditto.
Instead we do 100% transparent RTP proxying with mediaproxy. However, we did not want all that RTP traffic to pass through our servers so we __only__ proxy RTP streams when one or both SIP clients are behind a NAT __or__ when a client is accessing the voicemail system (see my other posts on how I have Asterisk on a 10.x IP network)
The benefit of doing NAT traversal this way is that we believe it scales very well and is the most simple to maintain and support. We've always taken the approach that we're going to put a million customers on our VoIP platform and RTP is a show stopper if you can't keep up with load demands.
We avoid this by making sure customers connect their IAD up as follows:
INTERNET ----- Broadband Router ----- IAD ----- PC
We can do this because we only support IADs that are routers, such as the UTstarcom iAN-02EX or the Grandstream 486. We also ship the IADs locked down so that customers cannot modify their settings. The UTstarcom allows us to remotely change the configuration. All this translates to users having their IADs with public IPs and therefore, RTP doesn't hit our servers.
Exactly! And that's the problem. If you are to support (like us), regular SIP phones hooked up on a router somewhere, you cannot do this. Either you proxy everything (which as you say, is very bad, indeed) or you use
STUN...
If a customer hooks up their IAD as follows, then they'd be RTP proxied for all calls, but since they are signing up with our service we send them instructions on how to hook up their IAD.
INTERNET --- Broadband Router ---- Switch/Hub --- IAD
In either case they fully function __without__ STUN, but like I said before, if they read the "installation instructions" that we include with the IAD then 9 out of 10 will hook up their IAD as noted before and therefore they'll have a public IP and they'll not have any RTP streams proxied, except for the voicemail access, which is always proxied because our Asterisk is not directly accessible to the internet.
But hey, we have now started to detail the reference design. What kind of UAs should we support? ;-)
We should support any RFC3261 compliant IAD. Our company prefers IADs that have router capabilities such as a UTstarcom iAN-02EX because the previously mentioned installation confuration is possible.
g-)
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers