My router is an A8000RU with MT7622 SOC, and HW offloading enabled.
When i use Microsip on my PC to make calls, after about 25/30s the call drop.
I don't have this problem with incoming calls, i tested during 1m20s without any drop.
What i found and tried is to increase these values
net.netfilter.nf_conntrack_udp_timeout_stream = 600
net.netfilter.nf_conntrack_udp_timeout = 600
i rebooted but it didn't change anything.
Something else i can check ?
i found that there is another value, i also tried to increase this value too, but no better result...
my SIP provider will say "use the box i gave you to fix the problem", he will never help me for this kind of problem.
ho really ? and how can i be sure about this ? all i read around the internet says : it's about NAT keepalive.
A loss of communication after x seconds means the loss of the UDP session in the router's NAT table. (As a result, it no longer knows where the packets should go on the return path, in the direction Internet->your phone).
Since UDP has no notion of session, the router must maintain a hypothetical table on each UDP communication with an arbitrary time limit.
This can be very short, like a DNS request (which lasts less than a second), or very long (maintaining a call for 1 hour).
So what do we do? Leave all UDP "sessions" for 1 hour (at the risk of DNS requests saturating the table and overwriting other sessions)?
That's why it's useful to have NAT keepalive to keep this session active in the eyes of the router, to tell it that the session is still in use and therefore that it shouldn't cut it off.
Please also test without (any kind of-) offloading enabled, just to rule out quirky interactions with that (which is generally much less tested than generic netfilter code, which runs as-is on any other device).
OK so i just disabled SW/HW offloading and tested with and without kmod-nf-nathelper-extra , after this i even restarted the firewall to be sure...and i still have the problem...
You could Wireshark on your computer and follow the VoIP data. Anything related to UDP being stateless should not apply during a call because there should be going packages back and forth constantly.
Wireshark knows a bit or two about SIP, so maybe there's some information at the protocol level, not at the network level.
Hint: If you install the "sshdump" plugin while installing Wireshark and if you install "tcpdump" on your router, you can even Wireshark the whole traffic your router sees in real time.
i checked 50x times, and tried 50 combinations...in the best case there is no drop but there is no sound...
But when i have the sound, it drops all the time...
Anyway, i asked my friend chatGPT what iptables command i can use to increase the UDP keep alive and here is the answer :
iptables -A INPUT -p udp --dport 5060 -m conntrack --ctstate NEW -m udp -m timeout --timeout 300 -j ACCEPT
unfortunately i forgot my router now use nftables so i asked it to convert this to nftables, and the the result is totaly wrong.
hummm
this is what i get after the call is dropped :
root@box:~# tcpdump -nni any port 5060 | grep '200 OK\|ACK\|BYE'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
^C0 packets captured
0 packets received by filter
0 packets dropped by kernel
it maybe the server end that's setup badly for NAT
you can try opening the audio ports (portforward to the phone)
you will have to lookup what one's are in use tho
tho I think the NAT helper links these
for asterisk side I'm using 10000-20000 UDP
if you luck you soft phone may tell you
what audio ports are allowed
and they should align with server side allowed ports ?
this could also be a codec problem if you have one way audio
test via limiting to "allow=alaw,ulaw"
so i asked it to convert this to nftables, and the the result is totaly wrong.