Degraded VoIP quality despite good bandwidth

binarysoul

We have two locations using VoIP, but the quality has been choppy, static and occasional dead air. We've confirmed there is plenty of bandwidth available at any given time, so that is not a factor. The protocols/codecs involved are Skinny, MGCP, RTP-I, RTCP and G.729.

I've read that the compression algorithim used in a VoIP environment could impact quality, but I also read that G.729 is the most popular codec.

Any ideas/solutions folks?

dtlokee

There are other factors that affect quality, what is the round trip delay, what is the varaiation of delay(jitter), are the voice packets getting stuck behind larger packets. The codec shouldn't be a problem unless it's a softphone taht can't process the voice fast enough (which I haven't seen). Are you using Call admission control and QoS throughout the network? Is the Voice traffic somehow being shaped to a traffic rate?

G.729 has a MOS of 3.9, where toll quality is a 4.0, and 2 people in the same room is a 5. It should not be choppy at all.

binarysoul

What are acceptable ranges for jitter and round trip delay? I've seen some number to that effect, but not sure what is good and what's bad.

Also, one site is on a DSL connection 3Mbps/640kbps downstream/upstream. I suspect DSL may be an assue here, but I've been told it's a guranteed rate, e.g. not residential. But I still suspect DSL may be a factor.

Plantwiz

You may need a T-1 (dedicated). Initially, we were told that lower speeds were acceptable, but it just wasn't the case. Mind you, you can 'get' a signal most of the time, but if you are using this for a business line.....you'll want it to be better to ensure your clients can hear you ALL the time.

Also, are you using a QOS switch? And how much distance between you and the ITSP? We had a twelve hop with our first and that just killed us with consistency of service.

dtlokee

One way delay should not be more than 150ms. Additionaly the speed of the DSL connection may be an issue. You may need to apply some outboud QoS, in particular LLQ to apply a minimum bandwidth for the VoIP packets. G.729 should require about 24-30Kb/s for each call. How are you routing throught the Internet? IPSec ot tunnel interfaces? All this adds overhead which can intorduce processing delay.

For jitter it should be as close to 0 as possible, but anything less than 20-30 ms should be acceptable.

JDMurray

This is only for VoIP and not full H.323 video teleconferencing? Skype over residential DSL and using a dedicated router port provides reliable and crystal-clear service for me. Is your ISP doing anything funny with QoS or packet traffic shaping? Some ISPs go out of their way to marginalize streaming protocols used by video and voice over non-leased lines.

binarysoul

There is no videoconferencing involved, only voice.

I still believe that the CODEC choice will impact voice quality and here is a quote and the doc link from Cisco:

"Although it might seem logical from a financial standpoint to convert all calls to low bit-rate CODECs to save on infrastructure costs, you should exercise additional care when designing voice networks with low bit-rate compression. There are drawbacks to compressing voice. One of the main drawbacks is signal distortion due to multiple encodings (called tandem encodings). For example, when a G.729 voice signal is tandem-encoded three times, the MOS score drops from 3.92 (very good) to 2.68 (unacceptable). Another drawback is CODEC-induced delay with low bit-rate CODECs."

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/1700/1750/1750voip/intro.htm

So, should I use G.11 since it has the highest MOS score, but also uses 64kbs, i.e. no compression?

dtlokee

Single encoded g.729 has a MOS score of 3.9 and is considered good. The problem occurs when you send the output of the single encoding through the process again and again to further reduce the size. I use G.729 all the time with no issues, and I think going to G.711 will only compound your problem.

I really need more information to give you definitive answers on what you should do

Pash

For a good quality call, 64k bandwidth is more than adaquent per user in most setups. This is provided you have a good Qos or traffic shapping rig to keep everything moving. I have allowed for this on a basic Voice over VPN setup, no jitter, no issues, just clear calls on basic 2mb ADSL Business Lines.

Ohh and ill get back to you with what codecs im using for the VOIP.

Cheers,

binarysoul

Today I was sent a log with jitters value of about 150, no packet loss across the board, average 25kbps per connection. The VoIP runs on Cisco 1750 router.

There is no congestion on the network. Plenty of bandwidth across the board, so I suspect it must be some mis-configuration on the router.

Oh one more question, what's the difference between a VoIP gateway and a VoIP server? Why would you wanna have both?

Pash

Haha saying that, I made a huge mistake, I left UDP flood protection ON on the juniper firewalls, Calls were being dropped every other call. OOOOOPPPPSSSSS

binarysoul

Here I'm back with my famous VoIP issue and it won't be the last time

In this episode of the show, the story is that bandwidth is not an issue, but some VoIP connections get 10k, others get 23k and we have yet to determine why all voip calls not get close 24k when bandwidth is availbe. Using G.729 codec.

Any ideas?

dtlokee

Are you using the running the voice through the codec more than one time? That would reslut in lower bandwidth requirements and lower quality speech.

vmaxwell

binarysoul wrote:

We have two locations using VoIP, but the quality has been choppy, static and occasional dead air. We've confirmed there is plenty of bandwidth available at any given time, so that is not a factor. The protocols/codecs involved are Skinny, MGCP, RTP-I, RTCP and G.729.

I've read that the compression algorithim used in a VoIP environment could impact quality, but I also read that G.729 is the most popular codec.

Any ideas/solutions folks?

Any VoIP deployment requires QoS tools to be used, otherwise the voice suffers as it's in the mix with normal data traffic. You need to look at classifying, marking and queuing for your voice. Also "serialization" may be an issue here. what's the line access rate?

Also what's the QoS level with your provider?