[TriLUG] More Asterisk Qs.. QoS
jonc at nc.rr.com
Tue Jun 20 22:50:51 EDT 2006
On Tue, 2006-06-20 at 11:30, Brian Henning wrote:
> Hiya Gang,
> Hardware issues aside, I'm having less and less good times with
> shoving an Asterisk call over a VPN. Here's what I'm encountering:
> When the VPN is established and essentially idle, I get ICMP round-trip
> times of about 70 - 80 ms. Not bad.
> When a call is in progress, the ping time skyrockets as high as 1250
> ms, and never gets much lower than 300 ms. Obviously, the longer the
> ping time (assume, for the time being [because I haven't tackled it yet]
> there is no QoS throttling taking place), the worse the problems with
> echo and garble become.
> This testing setup where I'm seeing this behavior is out through our
> cable ISP and back in through our DSL ISP. Traceroute conks out at hop
> 13 in the DSL->Cable direction; I imagine there's a router out there
> that is ignoring those packets. Hop 13 is on the right class-C, so I
> figure it's only one or two more hops at most to get the rest of the way.
> Enabling or disabling lzo compression on the VPN has no effect.
> So essentially, my questions become:
> 1 - Does this sound like just something I can fix with QoS tweaking? I
> have to admit embarrassingly that I really have no idea how to start
> adjusting QoS in our PIX-501.
I've never had a good experience with putting VoIP through a Pix
firewall. None. Nada. Nichts. Keinen.
My guess... the cpu sucks. It can't handle the load from the high number
of packets that come through every second. Also the Pix will buffer
*every* packet. No matter what. It's a fifo sucking time horror. Don't
ever use it for VoIP.
Perhaps I'm being ambiguous here. I think its your Pix firewall.
Now I'm sure some fine folks will leap to the defense of the Pix. That's
fine. The worlds a big place. I'm willing to listen. But my first
reaction when a client calls me and tells me they have a Pix firewall is
to pull a Linksys WRT54GL (the "L" stands for Linux) off the shelf and
pack it into my bag. By the time they finish describing the many, many
QoS problems they have been experiencing, I'm already in my car driving
to the site. An hour later - their Voice traffic will be crystal clear
and their Pix will be quietly collecting dust on an out of the way
> 2 - Since the VoIP traffic is shuttling across a VPN, the hardware
> handling the QoS isn't actually going to know it's VoIP traffic anyway;
> all it will see is VPN packets. I haven't scoured the docs too
> carefully yet, but does OpenVPN have internal QoS ability? Or is that
> something I should do just outside the VPN, such as with tc for example?
> I can up the priority of VPN packets themselves, but it won't always
> be VoIP traffic within the VPN.
> Continued thanks for all the friendly help. :)
I've shuttled VoIP traffic across an IPSec VPN using OpenBSD endpoints.
It worked fine. I think it would work better with a hardware based
solution - but the added latency due to the VPN was minimal. The CPU's
seemed to keep up with the traffic stream just fine.
Latency spikes across the connection were magnified by the use of the
VPN but it was barely noticeable. I think as long as your VPN endpoints
can handle the streaming load without buffering then your VoIP should
work fine. If there is any significant buffering though the tunnel won't
work for Voice.
More information about the TriLUG