Hi there

Java Rockx wrote:

Look at the <ser-source>/modules/rtpproxy

don't you mean modules/nathelper ? :-)

and <ser-source>/modules/mediaproxy directories.

There are README files. Personally, I'd recommend using mediaproxy because it seems to be more effective with handling NATed clients. There is a sample cfg file in the mediaproxy directory.

can comment on mediaproxy, but I'm using nathelper on SER 0.8.14 with rtpproxy (from CVS, the tar linked on voip-info.org don't work) and example found at

http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/nathelper.cfg?r...

and it worked at first, like a charm

in fact, it worked so well that I'm still asking myself if I was supposed to configure anything on clients to make it work or not (i.e. Outbound proxy or Stun server like in grandstream phones and adapters)

if anyone can enlight me on this, I'd appreciate

Cheers !3runo from Brazil

P.S. rtpproxy for SER 0.8.14 can be get with cvs -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co rtpproxy

Hi

Java Rockx wrote:

What I actually meant was using either rtpproxy with nathelper **OR** using mediaproxy.

ah, ok

Anyhow, when using rtpproxy with nathelper we've always had to allow specific UDP ports on end user firewalls.

that's the point. I didn't and it worked! that was impressive!

I don't know if my NAT boxes are smart or not (tested with DI514 and Linksys BEFS11W4). I just put the SIP server IP on grandstream config and nothing else (STUN, Outbound Proxy or NAT address are all empty)

the interesting part is that I'm having troubles ocassionaly with proxynat support using the same telephones and NAT boxes on FWD network. in fact, with SER, I was able to talk to FWD from my NATed client without problems! (the other way I'm still working with). that's the ser.cfg snippet:

# # is it a FWD destination? (3 xxxx) if (uri=~"^sip:3[0-9]+@") { # ... forward to gateways then; strip(1); rewritehostport("fwd.pulver.com:5060"); forward(uri:host, uri:port); break; } else { #

# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; };

does any of you knows if it is possible to redirect a ipkall.com account to a SER box? or to redirect a non-answered FWD account to another SIP account on a SER box?

Cheers !3runo

Andrei,

Thanks for the info. But if I understand you're comments correctly you're saying that either of these configurations work *without* putting holes in the client's firewalls:

Option 1) Use nathelper and rtpproxy

Option 2) Use mediaproxy

IMHO, I'd be surprised if my config was wrong when I attempted "Option 1" because I used nothing more than the example ser.cfg that comes with the source distro. My results were not good because all client side firewalls required specific UDP ports to be opened. I tried with the following UA's behind a 2wire DSL router:

Grandstream ATA 486 Grandstream BudgeTone BT100 UTstarcom iAN-02EX Sipura ATA Cisco 7960G Cisco ATA 186

So if my config was wrong, then does that also mean that the <ser-src>/modules/nathelper/nathelper.cfg file is wrong? Should I have used one of the other example nathelper CFG files?

All I know is that as soon as I switched to mediaproxy all my NAT issues evaporated.

Now assuming that my configuration for nathelper/rtpproxy was wrong, let me as this question; which method provides better scalability, nathelper or mediaproxy?

Regards, Paul

--- Andrei Pelinescu-Onciul pelinescu-onciul@fokus.fraunhofer.de wrote:

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

__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

Great. I'll try it again.

Would still like to know which is the preferred method and which method can handle a higher load of concurrent callers.

Regards, Pual

--- "Bruno Lopes F. Cabral" bruno@openline.com.br wrote:

Hello there

Java Rockx wrote:

...

Andrei, Thanks for the info. But if I understand you're comments correctly you're saying that either of these configurations work *without* putting holes in the client's firewalls:

Option 1) Use nathelper and rtpproxy Option 2) Use mediaproxy

IMHO, I'd be surprised if my config was wrong when I attempted "Option 1" because I used nothing more than the example ser.cfg that comes with the source distro.

I used the example config found at

http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/ser/sip_router/etc/nath...

...

My results were not good because all client side firewalls required specific UDP ports to be opened. I tried with the following UA's behind a 2wire DSL router:

Grandstream ATA 486 Grandstream BudgeTone BT100

I also tested these two, and they passed here with nathelper/rtpproxy

Cheers !3runo

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com