logo       

RE: SIP client registration issues with asterisk: msg#00038

security.firewalls.pfsense.user

Subject: RE: SIP client registration issues with asterisk

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:abel.martin.ruiz@xxxxxxxxx]
> Sent: Friday, December 29, 2006 12:59 PM
> To: discussion@xxxxxxxxxxx
> 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
>
>



<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise