Has anyone here dealt with VoIP issues when the ISP uses CGNAT? I’m running an ATA on a provider that uses CGNAT and I’m trying to figure out if others have seen similar behavior.
For anyone not familiar with CGNAT: instead of your router getting a true public IP, the ISP puts you behind a shared carrier‑grade NAT. So you end up with two IPs — an internal one assigned by the ISP and a single external IP shared among many customers. It generally works fine for most traffic, but it can complicate anything that relies on stable inbound connections, like VoIP.
My setup: Grandstream HT702 ATA behind an R7000 router. I’ve used this exact configuration on multiple ISPs without any issues. But on the one ISP that uses CGNAT, I occasionally get one‑way audio after about 10–15 minutes into a call. Everything starts fine, then suddenly I can hear the other side but they can’t hear me (or vice‑versa). Because this only happens on the CGNAT ISP, I’m pretty confident that’s the culprit.
I’m using TLS and SRTP, and I have keep‑alive enabled for both NAT and SIP. Has anyone found a configuration that plays nicely with CGNAT? Any tricks, settings, or workarounds that helped stabilize long calls?
I’ve tried it both ways — using STUN and using only Keep‑Alive — and I still end up with one‑way audio after about 15 minutes. STUN didn’t make any difference for me. I remember seeing a comment from another VoIP provider saying STUN can actually cause more issues when you’re behind CGNAT, but I never really understood the technical reasoning behind it or whether it’s universally true. All I can say is that in my case, STUN didn’t help at all.
Is your pfSense setup paired with a VPN or a VPS tunnel? I’m not sure how a router alone could solve the CGNAT issue without one of those in place. I’ve read that if I flashed third‑party firmware onto my R7000, I could configure a VPN, VPS tunnel, or reverse proxy to work around CGNAT — but I’m not sure I want to get into all that.
Sorry but…have you solved this?
Same problem here, but technically different from you, MAYBE.
Sometimes after 5 minutes…same thing. THEY don’t here us anymore.
This is very often related to SRTP not working (being blocked, etc). You can try very simple fixes at first like:
Disable SIP ALG / SIP Passthrough on your router. This is most of the time the only thing you have to fix. Most issues are with that, even on modern routers.
Then if this does not fix the problem, maybe try to increase any “NAT Keep-Alive interval” feature you might have on your device. And also SIP OPTIONS Keep Alive Interval = 20, and maybe SIP OPTIONS Keep Alive Max Lost = 3.
Well…I just checked the wiki again for the config of my HT801, and some settings were not set properly (by me…)
In a few days I will have some feedback from people in the house for sure.
Oh, yeah, the HT801. I had a HT701 and now have an HT803 after the first one died, but I must say that I have sub-optimal performances with it since I bought it. I never was able to find the source of the problem. After 24-36 hours, the device will think itself connected, but voip.ms sees it disconnected. The only solution I found so far is a hard reboot the device every night. (Home Assistant box with a “smart switch”.)
SRTP was the real problem for me witht he HT701. Once I figured that one out, including disabling SIP ALG / SIP Passthrough, I never had the “they can hear me but I can’t hear them” problem, and related issues like that. It took me a while to figure it out. Since then (and asside the strange problem I have witht eh device), this is working properly for long phone calls.
The power cable of my HT801 is connected to a power bar just next to my bedroom, the same for the main base of my old Panasonic cordless phones. It would be easy to reset it myself every night. I changed the settings when everyone is sleeping so I could not test myself yesterday.
Yes, all is working as expected, and we can have very long phone calls without issues.
The problem with my HT803 that I must reboot is not related to the same issue. This is something else. I never took the time to investigate it, as the quick reboot fix is enough. You will most probably never need to do that.
