[asterisk-users] New thread - SIP over VPN

[John A. Sullivan III]

On Sat, 2009-09-26 at 19:32 +0000, Jeff LaCoursiere wrote:
> On Sat, 26 Sep 2009, Alan Lord (News) wrote:
> 
> >
> > Hmmm, has anyone tried SIP over a VPN?
> >
> > We are thinking of testing this but haven't yet...
> >
> > Al
> >
> 
> I have a client with Sonicwall VPNs.  Asterisk is at head office on 
> internal LAN, six external locations all have Linksys 2102 ATAs and 
> Polycom IP501 phones registering and placing calls through the tunnels. It 
> seems to work fine, but there is plenty of bandwidth between the offices, 
> and they use G729.  I think wrapping up the UDP stream into a TCP based 
> tunnel might cause havoc if there is any packet loss or delay.
<snip>
We are using SIP over both IPSec and SSL VPNs very successfully with
access controls in the tunnel ingress via the ISCS network security
management project (http://iscs.sourceforge.net).  There are a couple of
issues.

I'm not sure what you mean by a TCP tunnel unless you are referring to
something like using OpenVPN over TCP rather than the default UDP.
IPSec tunnels (which we use for LAN-to-LAN connections) are an IP level
protocol and not TCP.  OpenVPN (which we use for remote access) defaults
to UDP port 1194 but can use any UDP or TCP socket.  There has been some
discussion that using it over TCP for VoIP can produce better results
because the packets are less likely to be delivered out of order
although perhaps with greater latency.

All VPN processes will introduce additional latency.  We have not found
that to be a problem but several rounds of encryption / decryption over
long distance connections in complex environments might introduce enough
latency to be problematic.  We have not found that yet.

Depending on your VPN protocol implementation, there may or may not be
an option to pass the ToS bits from the original packet into the IP
header of the VPN packet.  This is very important.  Even though the
Internet will not honor the ToS bits, you will want the gateways on both
ends to do so, especially the one placing the packets onto your last
mile.

Since the VPN gateways cannot look inside the packet until it is
decrypted, they have no way of distinguishing a large FTP packet from an
RTP packet.  Passing the ToS bits through may help.  However, be
careful.  Most VoIP implementations seem to be setting DSCP bits instead
of explicitly the ToS bits.  DSCP uses the ToS bits but in a way
different from the way ToS is set up to interpret them.  If I remember
correctly, setting DSCP to Expedited Forwarding sets the bits which
coincide with ToS in such a way that Linux based gateways will place the
packets into the band 1 which is the default processing band and not
band 0 which is the high priority band.  For example, on Asterisk, we
did not set our RTP QoS to b8 but rather to b0 (if I recall correctly).

We have one case using OpenVPN where the sound quality is occasionally
problematic.  In our case it's a little easy.  The remote desktops are
based upon our soon to be released SimplicITy model
(http://www.ssiservices.biz) and accessed via NX or X2Go technology.
Usually, the only traffic passing through the OpenVPN tunnel is the VoIP
traffic.  We have thus changed the gateway itself to treat all UDP
packets on port 1194 as high priority.  We'll see if that makes the
problem go away.

Hope this helps - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society