No subject

Enhanced OS.

General rules I use:
-Do not use SIP transformations (the VOIP tab), these cause random RTP =
issues, and once you start forwarding calls between users, all things go =
to heck. You are better off using NAT/qualify in your sip.conf.
-Do not use SonicOS Standard (all new Sonicwalls should come with =
Enhanced now anyway) as there is no method to increase the timeout for =
UDP rules, this will never be added to this firmware
-In SonicOS Enhanced, create inbound and outbound permit rules for all =
UDP traffic to your PBX (assuming it is on the WAN side), set the UDP =
timeout to 300 or more, this covers SIP and RTP, but you can be more =
specific if you prefer

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com =
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Bill =
Michaelson
Sent: Friday, October 24, 2008 13:41
To: asterisk-users at lists.digium.com
Subject: Re: [asterisk-users] Sonicwall potentially causing long ping =
timesto SIP phones

Kristian Kielhofner wrote:
On 10/23/08, Bruce Komito <brucek at bagel.com> wrote:
 =20
> We've had LOTS of problems with Sonicwalls doing bad things to SIP and =
RTP
>  connections.  I've seen the delay thing, as well as the Sonicwall =
throwing
>  away entries from the ARP table because of inactivity.  I've also =
seen
>  sporadic, intermittent problems with transfer from one phone to =
another.
>  I have no doubt that a new, properly configured Sonicwall can be made =
to
>  function properly in a VoIP environment, but we are not Sonicwall =
experts,
>  nor are many of the purported experts.  In every case where we've had
>  problems with VoIP behind a Sonicwall, the problems ALL disappear =
when we
>  put the phones on a LAN segment that does not pass through the =
Sonicwall.
>  So, now that's our going in position.  If it works, great, but if it
>  doesn't, our solution is to take the Sonicwall out of the picture.
>
>  My $.02 .
>
>  Bruce Komito
>  WPTI Telecom
>  (775) 236-5815
>
   =20
I wouldn't single out SonicWalls when it comes to breaking SIP traffic. =
Most of the "anything but simple PAT" devices I've seen that implement =
any SIP specific fixups usually end up breaking something along the =
line. Unless the product is from a company where SIP is their core =
competency (like Ingate, or /maybe/ Cisco) it's best to stay away and/or =
disable the SIP specific fixups wherever possible. I'm looking forward =
to the day when SIP-TLS is the norm and these devices have no idea what =
kind of traffic is flowing through them!=20
-
I sympathize, especially since a client of mine is facing the same =
situation.=A0 A potential update to their configuration involves exactly =
what you (Kristian) suggest: layering TLS in-between.=A0 I've run =
SIP/RTP and IAX over openVPN without issue routinely.=A0 What worries me =
is that the problem is not related to SIP awareness, and that some =
erratic performance by the Sonicwall that is benign in most =
circumstances manifests as a quality issue when carrying media =
streams.=A0 Seems unlikely, but does anybody have any clarity on this?