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?
