>From my experience, Sonicwall is a nightmare with SIP if you do not have >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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Michaelson Sent: Friday, October 24, 2008 13:41 To: asterisk-users@lists.digium.com Subject: Re: [asterisk-users] Sonicwall potentially causing long ping timesto SIP phones Kristian Kielhofner wrote: On 10/23/08, Bruce Komito <[EMAIL PROTECTED]> wrote: > 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 > 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! - 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? _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
