SIP re-invites behind dd-wrt v24 voip router

[325xi]

My PAP2T is behind dd-wrt v24 VoIP router.
I like the idea behind Milkfish to offload SIP/RTP guesswork from NAT to a separate engine, and it works when re-invites ar disabled.
Once I enable them I have one-way audio - I guess firewall blocks incoming RTP from "alien" host. But my understanding is that this is exactly what SIPPatH is supposed to handle - get the data from SIP and make rtpproxy, firewall, and NAT behave accordingly!

What's wrong? Are re-invites supported by Milkfish at all?

[DracoFelis]

Originally Posted by 325xi

My PAP2T is behind dd-wrt v24 VoIP router.

I also use DD-WRT, but gave up on the VoIP version of that router software for similar reasons. Yes, the VoIP proxy is nice if all you want to do is connect to "registered" VoIP services.

But as soon as you want to do something fancy (in your case "reinvites", in my case accepting SIP calls from strangers) the way the proxy is configured in DD-WRT seems to fail. And because those VoIP proxy settings are in a file on a READ ONLY directory in the router (at least they were the last time I looked into this issue), about the only way I could see to change those VoIP proxy settings is to compile yourself a customized version of DD-WRT (which seemed like a lot more work than I wanted to mess with).

IMHO you would be better off doing what I do. Just give up on the proxy (flashing back to the "standard" build, if you want to reclaim the resources used by the VoIP proxy), and tell your router to forward the SIP and RTP ports you are using to your adapter(s), and setup the adapters using STUN. If, like me, you have more than one VoIP adapter, be sure to adjust them to use different SIP/RTP port ranges, so that the forwarding can directly tell from the ports used which adapter to send the traffic to. If you do this properly, not only will "SIP Reinvite" work (assuming your provider supports it), but also things like inbound SIP calls will work.

NOTE: In theory this setup (I'm using) allows anyone on the internet to try to "hack" your adapters. But as long as you only forward the SIP and RTP ports (and not the web interface port), it should still be pretty hard for anyone to do much more (with those "open" UDP ports) than just send an unsolicited call to your phone...

[325xi]

AFAIK receiving calls from strangers isn't a problem with milkfish as long as you publish your homesip SIP URI. Homesip acts as dyndns and a kind of online directory, similar to ENUM. I didn't try it myself though.

I know I can achieve my goal allocating dedicated port ranges for every UA, but doing it using a "smart" SIP proxy with nat helper is so appealing.

I suppose re-invited calls can be handled by Milkfish if I open RTP port range manually - but I'm hesitating to do so as by this I'm opening a door into the router itself, not just useless for hackers ATA box.

The very idea is priceless, as it allows to use hosted Asterisk while having local calls handled locally, not passing 3rd party datacenters, which may be fairly crucial for sensitive business communications.

[DracoFelis]

Originally Posted by 325xi

AFAIK receiving calls from strangers isn't a problem with milkfish as long as you publish your homesip SIP URI. Homesip acts as dyndns and a kind of online directory, similar to ENUM. I didn't try it myself though.

Interesting, I didn't know that. However, I will admit my knowledge may be a little "out of date", as I haven't looked a lot into the VoIP proxy since the v23 days. So I guess it shouldn't surprise me much, that they have apparently enhanced the VoIP proxy options in v24.

Still, until/unless the VoIP proxy does something that I can't just as easily (and almost as securely) do with port forwarding and STUN, I still fail to see why I should bother using up router resources to run that proxy.

Originally Posted by 325xi

I know I can achieve my goal allocating dedicated port ranges for every UA, but doing it using a "smart" SIP proxy with nat helper is so appealing.

I agree it's appealing in an abstract sort of way.

However, sometimes the KISS (Keep It Simple, Stupid) Principle is best. While a fancy VoIP proxy in the router might be "elegant", simply using STUN and forwarding ports (and not even worrying about the VoIP version of the router software) does the job (at least for me), while still being simple and using few resources. It may not be "elegant" (like a VoIP proxy is), but it gets the job done with a minimum of fuss.