On Nov 13, 2004 at 15:09, Java Rockx javarockx@yahoo.com wrote:
What I actually meant was using either rtpproxy with nathelper **OR** using mediaproxy.
I've had better success with mediaproxy because rtpproxy/nathelper seem to still require users to open UDP ports for SIP and RTP in their firewall whereas mediaproxy does not require end users to do anything to their firewall.
You're wrong. There is no difference from the firewall point of view between mediaproxy and nathelper. If one setup works with one of them it should work also with the other. You probably misconfigured somehow nathelper, or your test setup was a little different. The only other possibility I can think of, is somehow the RTP ports allocated by default by rtpproxy are blocked by your firewall and the ones allocated by mediaproxy are not (lucky coincidence).
My experience has been that when using mediaproxy a STUN server isn't necessary, although I'm have some problems right now with sems/sipums voicemail because it is trying to send RTP media to NATed clients on non-routeable IP addresses.
Yes, STUN is not necessary, but if you can use it it has some advantages (you get less traffic and RTP has lower delay). On the other hand there are situations when STUN will missdetect a NAT type, or it won't ever try to detect it (very common with some UAs). Using nat_uac_test("19") might help catching some of these cases.
Bottom line: mediaproxy / nathelper will work in almost all cases, STUN will not work always, you can combine the two of them.
Andrei