Hi, We have been recently experiencing problems with SIP clients registration. We have an asterisk box working as SIP server behind a NAT and some SIP clients behind a pfSense box.
After a lot of troubles we discovered that the problem was that SIP OPTIONS packets are sent to asterisk every 1 minute, which coincidentally is the state timeout for UDP traffic. There's no way of tweaking this parameter in our asterisk. So, when a SIP client got SNATed the state created was kept only for 1 minute, too. The consequence was that SIP clients were randomly unregistered, because when asterisk tried to contact them the state timeout might have expired. We solved the problem increasing udp.first, udp.single and udp.multiple values higher than 120 seconds by hand (actually we set 240 s, to be more conservative). We are not using static ports, since there are several SIP clients behind the pfSense box, so the port needs to be changed when SNAT is applied. Every extension is set in asterisk to have nat=yes, externip=x.x.x.x, and qualify=yes, which is correct. Related to this, I've seen on the forum that you recommend to change the to conservative: http://forum.pfsense.org/index.php/topic,2684.msg15914.html#msg15914 The problem is that UDP timeouts are not changed when setting on this option, and since SIP usually goes inside UDP payload it doesn't do the job. - Normal ----- # pfctl -s t tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s - Conservative ----- # pfctl -s t tcp.first 3600s tcp.opening 900s tcp.established 432000s tcp.closing 3600s tcp.finwait 600s tcp.closed 180s tcp.tsdiff 60s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s Shouldn't this option also modify non-TCP traffic timeouts? Regards, Abel
