VoIP Quality Fine Tuning

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


Hey there all,

I’ve narrowed it down: poor bandwidth quality. So, for the record, it doesn’t seem that Hyper V is the culprit. I was able to purchase two G.729 channel licenses and make some test calls successfully using that codec. HUGE improvement; night and day.

I am, however, having difficulty with allowing only certain endpoints to use G.729. Basically, we have one location that has pretty shotty bandwidth. Speeds can be up to 30Mbps, but jitter is sometimes 70ms, and calls either sound terrible or drop often. I’m looking for pointers on setting up a group of endpoints, which are part of a larger server, to use G.729, while everyone still uses ulaw. I’ve done a lot of playing around and research on a test system, including reading through a few posts on this forum, but I’m just not getting it.

Any advice is greatly appreciated.

I answered my last question:

The FreePBX GUI, though it appeared to, didn’t actually install the digium g729 module. Once I followed their CLI instructions (plus using the “lib64” folder instead of the “lib” one show in the instructions, as our server is 64 bit), everything worked great.

Big clue that the digium GUI tool didn’t work was that I couldn’t run the asterisk CLI “g729 show licenses” command, but I could after I ran the CLI install.

Gotta say that your problems are possibly not solved yet.

It is unclear that the success you had was due to using g729, because apparently that was not possible at the time if it was not installed (pass-through would work though), you mentioned earlier that your worst site had 20M bandwidth and a “jitter” of 70ms (you probably meant “delay”) but that would not cause hangups and 70ms would only be noticeable to the most discerning ear.

So one channel of g729 needs maybe 40kbs , g711 needs about double that, so two calls/four calls would only make your “poor bandwidth quality” as you make more calls.

But if works, then don’t question further :wink:

Ya, my initial test may or may not have been setup correctly. It’s hard to tell right now. I purchased some more licenses and am setting up all the endpoints right now for g729. I’ll be able to test once they’re back in the office tomorrow AM and I’ll let you all know what happens.

g729 is maybe a good choice for a slow dsl connection, but I don’t think that is your problem. You will ultimately need to correct your “poor bandwidth quality” and that absolutely starts at your vm-to-real network interface, all other things being equal

So, we have g729 set on the endpoints at that problem location. I’ve made a few test calls this morning. The call quality is definitely better, but you still can hear cutting out here and there.

I hear what you’re saying about the VM’s possibly being the cause dicko, but we have multiple sites all tied into the same server through site-to-site VPNs, and only this site has this level of quality issues.

To hone in a little deeper, out of seven sites, three of them have complained about voice quality. Two of the sites are hard to reproduce, but if you listen for a long time, you’ll get some bad audio here or there. The third site, which is the one where we have g729 setup now, is the really bad one, though the new codec has made some notable improvement. The other four sound just fine. That being said, it seems like the problem might be at the provider level.

The two locations that have only had a couple complaints are both timewarner business. I’ve heard they limit RTP sometimes. Is there a way to work around this?

The bad location is in a fairly remote location through a provider called Ayera. They use Ubiquiti microwave antennas to get that locations a connection of 25/10Mbps. Of course I thought that the wireless nature of the circuit was the culprit originally, but after contacting their support team, they said that they had some quality score that the connection was showing, which is supposed to mean VoIP quality is great.


Also, I haven’t played around is the Asterisk CLI much, but in the past few days, I’ve notice lots of warnings and errors as I’ve had it open. Not sure if that’s normal, or if they could be leading to a cause of our quality issues.

Common errors:
ERROR[13345]: res_clialiases.c:193 load_config: res_clialiases configuration file ‘cli_aliases.conf’ not found
ERROR[14379]: res_config_ldap.c:1634 parse_config: Cannot load configuration file: res_ldap.conf
ERROR[14379]: res_config_sqlite3.c:1107 parse_config: Missing config file 'res_config_sqlite3.conf’
ERROR[14379]: phone_message.c:1645 build_dialplan_routing: Unable to build dialplan routing - invalid license

Common warnings:
WARNING[46922]: chan_sip.c:30808 build_peer: ‘tcp’ is not a valid transport type when tcpenable=no. If no other is specified, the defaults from general will be used.
WARNING[46922]: chan_sip.c:30808 build_peer: ‘tls’ is not a valid transport type when tlsenable=no. If no other is specified, the defaults from general will be used.
WARNING[14669][C-000005c9]: ccss.c:1000 ast_set_cc_callback_macro: Usage of cc_callback_macro is deprecated. Please use cc_callback_sub instead.
WARNING[14745][C-000005cf]: func_channel.c:538 func_channel_read: Unknown or unavailable item requested: ‘reversecharge’

As with all network problems, it all depends on the route and the routers involved, a very quick touchstone is mtr (install it if you need to) which shows packet loss and latency continuously to a particular host. Use udp (the -u option) for a more accurate view.

Wanted to update everyone on this:

We’ve seen some major improvements, and here’s what’s been done:

-We setup G.729 to certain endpoints. We definitely saw immediate improvements, but shortly after started getting complaints about some calls being very quiet. This was probably due to poor transcoding happening somewhere along the route.

-I started reading about mtr, and how to run reliable tests, and ended up running the VoIP test from this website: http://myspeed.visualware.com/indexvoip.php Right away, we were seeing high packet loss and high jitter from our main problem site. Other “semi-problem” sites showed similar, but not as poor, results. So I still haven’t played with mtr, but I’ve definitely seen a clear correlation between our poor audio quality sites and those that seem to have no problems by the results from the VoIP test URL above.

-I then dug deeper, with a fresh mind, and came across “jitter buffers”. Due to RTP packets arriving out of order, or severely delayed, they can be dropped and thus you hear breaking, weird sounds, poor quality, etc. Well, I read Jerry Warner’s reply on this post Enable Jitter Buffer and it changed my life.

On our FreePBX server, under Settings->Asterisk SIP Settings->Chan Sip, I enabled Jitter Buffer, and then set Force: Yes, Implementation: Adaptive, and Jitter Buffer Size: 300/500.

Our main problem site, as well as our semi-problem sites have great audio now! And we are using G.711, not G.729 per the quietness I explained above. Admittedly, I’ve heard a crackle here or there, but never any actual loss of a whole word or two like we were getting before. From what I understand, SIP devices have built in Jitter Buffer’s, hence FreePBX’s is disabled by default. Well, for really bad connections, the standard Jitter Buffer built into SIP devices doesn’t provide enough time for the delayed RTP packets to arrive and placed back in order before playing the audio through your receiver. By forcing the Buffer, you force the longer-than-default buffer size, and thus give more time for those laggy packets to be received and placed in order.

This does of course cause a delay in the audio, but it is not noticeable (I would say it seems less delayed than most cell phone conversations).

Anyway, a very non-technical and possibly somewhat erroneous analysis, but my hope is this will give some hope to those who are struggling with audio quality issues.

1 Like

As per my experience with the 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.
You can also use this kit in production.

I already wrote those same words above.
Copying is a nice form of flattery. :slight_smile: