VoIP Quality Fine Tuning

We’re on FreePBX 12.0.65

Like others have posted, we’re having some voice quality issues. I have multiple people tell me “you sound like Darth Vader”. Whether this is on inbound or outbound calls doesn’t really matter, as usually both parties are users connected to one of our FreePBX servers.

What I’m posting for is in hopes that some of you may have similar setups and may have already done a ton of the legwork. I spent several hours poking around, but I’ll read some long article talking about QoS and other things, have a basic understanding, but still not know how to implement it into our system.

Here’s our setup:
-Anveo Direct as VSP
-Various “routes” (upstream providers) selected. Routes calculated by lowest cost and best quality.
-Various ISP’s at various sites (Verizon, TimeWarner, Telepacific, Cox, Internap)
-All sites tied through ipsec VPN from their SonicWalls to a single HA Cisco ASA setup
-On SonicWalls: all features unchecked on VoIP page
*Some of our SonicWalls have QoS settings, some do not due to licensed version or lack of
-On ASA, inspect sip removed from config

If any of you have some suggested settings that we could use as a basis, before we dig deep with monitoring and whatnot, that would be fantastic. Thanks in advance!

No one huh? No wonder I can’t find any solid direction online about this…

1 Like

You say nothing about your FreePBX install as to hardware, OS, network etc. My guess, No takers until you do

Although I do not have an answer for you, I have seen latency/bandwidth issues cause (robotic) sounds on voice, my guess is that your internal calls are flawless. Maybe the issue could be with VPN? hard to say…


We’re on FreePBX 12.0.65 "FreePBX Distro"
Hardware is:
Hyper V 2012 R2 Virtual Machine w/ the CentOS integration services installed
4GB RAM, 2 Dedicated CPU Cores
Cisco ASA 5510 HA Cluster is VPN "server"
Various sites are setup with site to site VPN via Cisco ASA or SonicWall TZ 100,105,etc.

I would start with running MTR on your server to one of your locations over the VPN to see if you have any latency issues. If you have a g729 license, you could try moving to that codec to reduce bandwidth. Thats how I solved some of my high latency endpoints.

Very cool. I’ll give MTR a look (have no idea what it is) and see what g729 licensing costs.

Thanks for your input.

I would suspect your hyper-v system.

1 Like

Why do you think that dicko? CentOS is fully supported with Hyper V integration services.

We host many CentOS VMs and have no problems (though we did have some networking issues before we installed integration services)

Because there is too much potential BS between you virtualization layer and your hardware layer, just try it on another modern virtualization platform like KVM, all your problems will go away. Centos might be supported, but you will likely have problems with kernel timing and RTP flows while it supports the underlying OS doing whatever M$ does “with priority”

1 Like

Hi dicko, thank you for the response.

We have a lot of time and energy invested in to our FreePBX servers that are running on Hyper V across several physical servers. Is there a way we could verify that kernel timing and RTP flows are where the quality issues are coming from, before we spend many many hours moving things over to a different hypervisor?

I’m sorry, I can’t answer that. by the time you have a machine, it is really not analyzable, you would have to do that at the host level.

But if there are noticeable problems with them, then my guess it is the host machine producing such “artifacts” the old fashioned dahdi_test -vv might show something but generally modern asteri use kernel based timing , and the kernel you are using is running on “who knows what I am doing” :wink:

Dicko, thanks. I always appreciate your input.

would that command help me narrow down the cause of the bad quality? There are just so many variables, I would really like a fairly dependable “sure thing” in regards to the cause. For example, if I could determine for sure if it’s the trunks I’m using, that’d be fantastic.

Well “bad quality” is invariably missing/wrong data, comprehensively you could capture the RTP packet streams into a file , then analyse them for missing/badly timed packets, a quick check would be to look at the logs after

rtp set debug ip n.n.n.n

there will be timestamps on every packet, and out of sequence or missing packets are quite obvious

You never replied if the problem happens on internal calls. That would Elim ate the hyper V if internal calls are dine. If you don’t make many make an internal destination for music on hold and listen to it for an hour. Any timing issues will be obvious.

I too have to second Dicko’S comment on KVM, it is proven to work well with Astersisk. I am sure that you have an awesome scalable virtualization platform however a phone system is a real time app and requires a different infrastructure approach.

Hi guys, sorry for the delay. Thanks for all your input…

I believe internal calls are okay, but can’t be sure. I will do that music on hold test. If that test passes, I can definitely eliminate hyper v as the issue?

I know nothing about KVM…just did a quick search and found out it’s open source and a preferred hypervisor for linux. I will definitely take a look into it.

On the subject of VM’s.
Mostly for any testing or backup purposes, we run a FreePBX guest in VirtualBox, on a CentOS host.
No special equipment, just low-end commodity hardwares.
No problem with call quality. (I prefer G.722 wideband audio.)
We’ve also sometimes used this kit in production. It works.

Fast and furious way to try out KVM with a nice GUI


(It’s on Debian) , just boot the iso . . .

add clustered servers and nbd storage with a click of a button (almost :wink: )

For all modern virtualizations make sure you have vt-x and vt-d (or equivalent) on your hardware and that they are enabled.

Can we simply move our VMs over to KVM, or do we need to start with fresh FreePBX installs?

There are many ways to , start with