Dear all, I believe that there is a bug either in my brain or in nf_conntrack_sip. I am running an Asterisk PBX behind a Linux firewall the rules of which I have developed myself. Since a while, inbound VOIP (SIP) calls are reaching the PBX only sometimes, and outbound calls get interrupted after exactly 15 minutes (900 seconds). Asterisk is configured to use only UDP, so there can't be problems with TLS or TCP. While I was debugging the issue, I have noticed the following: When Asterisk re-registers an endpoint with the SIP trunk, nf_conntrack_sip correctly adds an appropriate entry to the expectation table. I have verified this by conntrack -L | grep <SIP_PROVIDER_IPs>). But there is a problem: The lifetime of the expectation is wrong. Although I am giving the parameter sip_timeout=900 to nf_conntrack_sip when loading it, the lifetime of the expectation which is triggered by Asterisk's re-registrations is always 180 s (probably some default value). Initially, I thought I was using a wrong parameter syntax when loading nf_conntrack_sip, but I have verified that there is the correct value in /sys/module/nf_conntrack_sip/parameters/sip_timeout Now I am out of ideas. Could anybody please explain why the (re-)register from the PBX creates the correct expectation, but with wrong lifetime, despite the responsible module (apparently) is loaded with correct parameters? Thank you very much in advance, Binarus P.S. The following doesn't have to do with the above question, but I'd like to explain shortly why this leads to calls being interrupted after 15 minutes: My PBX re-registers every endpoint with the SIP trunk at an interval of 600 s. Therefore I have chosen sip_timeout=900 as parameter for nf_conntrack_sip. So far, so good. My SIP trunk is Deutsche Telekom AG; they send SIP UPDATEs and REINVITEs every 900 s during an ongoing outbound call. It is quite likely that this happens during a phase where the expectation which was created by the previous registration has timed out, so these SIP packets are blocked by the firewall in most cases, which finally makes the trunk or Asterisk end the call. If the expectation would live for 900 s as intended and expected, it would always be there because it would be "refreshed" every 600 s by the re-registrations, and hence the UPDATEs and REINVITEs would not be blocked. I could probably solve the problem by telling Asterisk to re-register every 150 seconds, but that is only a last resort. I really first would like to understand what is going on here. I can surely remember that nf_conntrack_sip was respecting the parameter sip_timeout with at least one previous kernel version. When installing Asterisk for the first time (about 3 years ago), I did the same tests and remember that the expectation was shown by conntrack -L with a lifetime of 900 s (immediately after having triggered it) and using the same parameters for nf_conntrack_sip.
