Not an answer to the original question but I think supporting this bounty might 
solve the issues too and even other issues that come along with sip behind nat: 
http://forum.pfsense.org/index.php/topic,2824.0.html

Holger 

> -----Original Message-----
> From: Abel Martín [mailto:[EMAIL PROTECTED] 
> Sent: Friday, December 29, 2006 12:59 PM
> To: [email protected]
> Subject: [pfSense-discussion] SIP client registration issues 
> with asterisk
> 
> 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
> 
> 

Reply via email to