<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ccffff" text="#000000">
<pre wrap="">Kristian Kielhofner wrote:</pre>
<blockquote
cite="mid:mailman.25440.1224800585.10646.asterisk-users@lists.digium.com"
type="cite">
<pre wrap="">On 10/23/08, Bruce Komito <a
class="moz-txt-link-rfc2396E" href="mailto:brucek@bagel.com"><brucek@bagel.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""><span class="moz-txt-citetags">> </span>We've had LOTS of problems with Sonicwalls doing bad things to SIP and RTP
<span class="moz-txt-citetags">> </span> connections. I've seen the delay thing, as well as the Sonicwall throwing
<span class="moz-txt-citetags">> </span> away entries from the ARP table because of inactivity. I've also seen
<span class="moz-txt-citetags">> </span> sporadic, intermittent problems with transfer from one phone to another.
<span class="moz-txt-citetags">> </span> I have no doubt that a new, properly configured Sonicwall can be made to
<span class="moz-txt-citetags">> </span> function properly in a VoIP environment, but we are not Sonicwall experts,
<span class="moz-txt-citetags">> </span> nor are many of the purported experts. In every case where we've had
<span class="moz-txt-citetags">> </span> problems with VoIP behind a Sonicwall, the problems ALL disappear when we
<span class="moz-txt-citetags">> </span> put the phones on a LAN segment that does not pass through the Sonicwall.
<span class="moz-txt-citetags">> </span> So, now that's our going in position. If it works, great, but if it
<span class="moz-txt-citetags">> </span> doesn't, our solution is to take the Sonicwall out of the picture.
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span> My $.02 .
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span> Bruce Komito
<span class="moz-txt-citetags">> </span> WPTI Telecom
<span class="moz-txt-citetags">> </span> (775) 236-5815
<span class="moz-txt-citetags">></span>
</pre>
</blockquote>
<!---->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 <i class="moz-txt-slash"><span
class="moz-txt-tag">/</span>maybe<span class="moz-txt-tag">/</span></i>
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!
<div class="moz-txt-sig">-</div>
</blockquote>
I sympathize, especially since a client of mine is facing the same
situation. A potential update to their configuration involves exactly
what you (Kristian) suggest: layering TLS in-between. I've run SIP/RTP
and IAX over openVPN without issue routinely. 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. Seems
unlikely, but does anybody have any clarity on this?<br>
<br>
</body>
</html>