Poor call quality with SIP Trunks (via VoipTalk.co.uk)

I am constantly getting complaints form my users of poor call quality via our SIP trunks that are hosted with VoipTalk.co.uk. We have a 10Mb Fibre internet connection with BT.net, so bandwidth is almost certainly not the issue and I have been working with BT to ensure that we have a good quality connection with no packet loss etc.

We only use the Trunks for outbound calls as our inbound calls come in via an ISDN line.

Our FreePBX server is on our internal network behind a Juniper SSG140 firewall and I have configured the firewall to allocate at least 1mbps bandwidth to VoIP traffic.

FreePBX 2.5.1
Asterisk 1.4.22

Our SIP Trunks are configured as follows:

type=friend
username=voiptalk_id
secret=voiptalk_pw
fromuser=voiptalk_id
host=voiptalk.org
dtmfmode=rfc2833
fromdomain=voiptalk.org
context=default
insecure=very
qualify=yes
autoframing=yes
jbenable=yes
jbimpl=adaptive
canreinvite=no

with a register string:

voiptalk_id:[email protected]/voiptalk_id

Does anyone else in the forums use VoipTalk UK and do they have a better experience that I, if so what are the SIP Trunk settings that work for you?

Or, has anyone had similar problems with VoipTalk and moved to another provider that gives better quality? If so, which provider?

Regards,
Dave.

can you be more specific about call quality?

Audio dropping? jitter? you sound like you are talking through a tube? high on helium?

You don’t say if you are using a compression codec or not. Adding compression will effect quality to start. What are you doing with these calls? Recording them also? The load on the server will also effect the quality if it is high.

What is the load on your local network? It your internal network is being stressed or the connections between the phone and the server are having issues then there will also be issues.

There are many places and things that can impact quality. So can you be a bit more specific.

It seems to be a combination of Audio Dropouts and Jitter - mostly on the inbound audio (when asked the called party normally indicates that they are receiving audio loud and clear).

The local network shouldn’t be too highly stressed - we’ve only got about 20 Windows XP PC’s and a number of Servers on it (The Servers are on Gigabit switches, and the XP boxes are on 100mbps switches, there are no hubs).

Since I posted, I’ve enabled QOS on the firewall with a DSCP value of 46 and amended the DSCP value from 48 to 46 on our Grandstream handsets. Most of our users are using either the Grandstream handsets or X-lite.

I’ve also set the Grandstreams to use the G729 codec and enabled G729 on the Asterisk Server (using the opensource g729 codec - I’m not sure exactly how legal this is, but I’m only using it to enable the Grandstreams to call the X-lite’s and voicemail). The X-lite phones are using Alaw. Setting the Trunks to use g729 (with canreinvite=yes), just caused everyones audio to sound like they were in a fish bowl so I backed out to allowing g729 and alaw.

I’ve also been running a trial with another VoIP provider for some of our calls and while the trial was running, we didn’t have any quality issues. It looks like it might just be that sending all of our calls via VoipTalk was causing the problem. Time will tell I think once I’ve switched on the new provider for a longer period of time.

Dave.

You really need to look at your Internet traffic. Even a 10 Mbps pipe will fill up and when it does, voip quality will suffer. Take a look at the traffic graphs on the Juniper and see how full your pipe it. Just an example 20 users listening to CD quality audio streams will consume half of that pipe.

Since your are transcoding G729, you should take a look at your phone server load also. It takes a little horsepower to transcode from one codec to another. I usually don’t run a compressed codec to a VOIP carrier. With an uncompressed codec, if you loose a packet or two, it is not a big deal. With a compressed codec, if you loose a packet or two, that is a substantial amount of audio and the decompression algorithm has to retrain.

I’ve looked at the traffic graphs and it really doesn’t look like bandwidth is a problem.

I take your point about the G729 Codec though and I’m going to remove it - it seems to cause no end of bother anyway and I only installed it to see if it would have a positive effect.

Hi there,

Have you tried http://www.testyourvoip.com/.

It may not help, but it’s fun. After you have done the test, you see in “See Detailed Results” lots of helpful information.

Regards - Colin
colin2710

I’ve tried that and a number of other similar VoIP testing sites, but they all indicate that we should be getting good quality calls.

Regards,
Dave.