I have recently replaced my ISP-provided modem with an OpenWrt device. I still use the ISP's VoIP phoneline, which was handled by my ISP modem. I have bought a Cisco SPA122 ATA to use the SIP VoIP landline. When I enter the ISP's SIP details (proxy, realm, user/pass, etc), the status becomes "Registered".
However, I'm unable to make phonecalls (neither in nor out). In the ATA, I can see SIP traffic going both ways, but there is no inbound RTP traffic. So I'm assuming there's something wrong with routing or firewalling of RTP traffic in OpenWrt.
The documentation on SIP/RTP says to install the kmod-nf-nathelper-extra package, but this makes no difference. I've also tried the rtpproxy package, and tried to forward the RTP ports to the ATA. Still, no RTP traffic is received by the ATA.
It seems that a lot of documentation is fairly old, from before the switch from iptables to ntftables, so I'm not sure how to troubleshoot this any further. Does anyone have an idea on how to proceed?
Note: my ISP also provides IGMP based IPTV, for which I run igmpproxy. I don't think this should interfere, since RTP is UDP-based, but I can't exclude the possibility either.
Don't try to cheat your provider by using NAT helpers, STUN, etc. and don't install any extra package for SIP/RTP. Don't forward ports.
Ask your VoIP provider for help or switch to another provider who can offer configuration support and troubleshooting.
You'll find that any (S)RTP traffic must be statically forwarded to the ATA, by forwarding a pre-defined range of UDP ports - look at what the ATA device uses as its default range. Your best bet is to put the ATA in a DMZ if you think a static forward is risky.
What you might find is in the SIP signalling, the ATA uses its LAN defined IP, unless you configure it to masquerade using your WAN IP. Verify with a pcap that a) RTP arrives to WAN IP b) what IP is sent in the SDP.
Before trying the packages and port forwarding, my OpenWrt config was 'plain' and it didn't work. I've copied the ATA configuration from screenshots of working deployments. So my only conclusion can be, that it must be something on the OpenWrt side.
I have tried forwarding the RTP ports, that doesn't work.
Is this what siproxd is supposed to handle?
These are already set in the ATA, indeed.
As indicated in the first post, installing and enabling the kmod-nf-nathelper-extra package makes no difference.
I'm guessing it's your SIP provider that can't or won't support NATed endpoints.
Please keep in mind that any advice given here is wrong by default as it is not based on the real call analysis. Speak to your provider or analyse your SIP/RTP traffic yourself if you can.
Your router is not guilty yet.
I live in Europe, where ISPs are by law required to support non-ISP equipment. My ISP provides all the info to install a private-owned ATA or SIP-phone, and there are numerous of cases documented where NAT'ed ATA's, SIP-phones, etc work. I have copied the settings in my Cisco ATA from a known-working deployment, but still I only get the SIP account as 'Registered' with no incoming RTP traffic.
I have copied setting-for-setting everything from a working Cisco ATA into my Cisco ATA, and you're saying OpenWrt is definitely NOT to blame? Then why does the OpenWrt wiki contain multiple entries for how to deal with SIP traffic? Are there many packages for dealing with SIP and/or RTP traffic etc? This is not about blame, but about finding a working solution.
For starters, you need to prevent the ATA from sending its actual (internal) IP address in SDP messages, so set the router's WAN IP in the EXT IP field.
I've been able to fix this issue. For sake of documentation, I'll post my findings.
First of all, I was thrown off-course because my SIP account was 'Registered' in the ATA. RTP traffic wasn't coming through, so I suspected that to be the cause. Turns our, not all SIP packets are created equal... Even though my SIP account was registered, Wireshark showed that not all SIP traffic made if from my ISP to my ATA. That's why I couldn't receive incoming calls, and SIP packets for outgoing calls didn't make it back, so again no call could be established.
So something strange was happening with the SIP traffic. The wiki says that SIP passthrough requires the kmod-nf-nathelper-extra package, so I had that installed on my router. This package actually turned out to be the culprit. When I removed that package, incoming/outgoing calls were possible again.
So in the end, OpenWrt both was and wasn't responsible for the issue. It's just that the documentation is wrong on this point. Or at least it was for my specific combination of ISP/SIP/ATA.
