i noticed this when my voip phone mysteriously stopped ringing. i use a tp-link router as a gateway which i'm certain is running linux/netfilters, though i don't know what version. i've observed the same problem on my raspberry pi running iptables v1.8.2. usually the first thing a sip client does is register with the provider's server. this has the effect of punching a hole through any firewalls in its path. after that initial registration, my provider keeps the connection alive by sending messages every 60 seconds. when netfilters sees traffic moving back and forth, the connection should transition to the assured state and set the expiration timer to nf_conntrack_udp_timeout_stream, which by default is 120 seconds. but in this case the timer is reset to nf_conntrack_udp_timeout, which is 30 seconds. the connection does not appear as "assured". pi@zawardo:~ $ sudo conntrack -L | grep 5060 conntrack v1.4.5 (conntrack-tools): 26 flow entries have been shown. udp 17 3 src=x.x.53.184.sip dst=x.x.126.73 sport=5060 dport=5060 src=x.x.126.73 dst=x.x.53.184 sport=5060 dport=5060 mark=0 use=1 this means that the connection is already expired before the first keep-alive arrives. if the router is using nat or filtering new connections then the messages bounce back until the client opens a new connection from inside. pi@zawardo:~ $ sudo tcpdump -i ppp0 udp port 5060 or icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 16:28:46.010042 IP x.x.53.184.sip > sip.example.com.sip: SIP: REGISTER sip:sip.example.com:5060 SIP/2.0 16:28:46.018303 IP sip.example.com.sip > x.x.53.184.sip: SIP: SIP/2.0 401 Unauthorized 16:28:46.021205 IP x.x.53.184.sip > sip.example.com.sip: SIP: REGISTER sip:sip.example.com:5060 SIP/2.0 16:28:46.030034 IP sip.example.com.sip > x.x.53.184.sip: SIP: SIP/2.0 200 OK 16:28:46.031020 IP sip.example.com.sip > x.x.53.184.sip: SIP: OPTIONS sip:zawardo@x.x.53.184:5060 SIP/2.0 16:28:46.031326 IP sip.example.com.sip > x.x.53.184.sip: SIP: NOTIFY sip:zawardo@x.x.53.184:5060 SIP/2.0 16:28:46.034408 IP x.x.53.184.sip > sip.example.com.sip: SIP: PUBLISH sip:zawardo@xxxxxxxxxxxxxxx:5060 SIP/2.0 16:29:46.030460 IP sip.example.com.sip > x.x.53.184.sip: SIP: OPTIONS sip:zawardo@x.x.53.184:5060 SIP/2.0 16:29:46.030587 IP x.x.53.184 > sip.example.com: ICMP x.x.53.184 udp port sip unreachable, length 492 16:29:46.530506 IP sip.example.com.sip > x.x.53.184.sip: SIP: OPTIONS sip:zawardo@x.x.53.184:5060 SIP/2.0 16:29:46.530619 IP x.x.53.184 > sip.example.com: ICMP x.x.53.184 udp port sip unreachable, length 492 i've tested this with a few different sip servers and it doesn't matter whether the pi is forwarding the connection or initiating the connection itself. before you ask me to update netfilters, just know i'm more interested in learning why this occurs since it seems to be contrary to what i know about how connection tracking should work. if it is a known bug affecting older versions of netfilters then i would appreciate any documentation that might persuade tp-link to update their firmware. yours, eray
