VoIP Latency Problem? [Telecom]

Hello,

We currently have a very simple VPN from our US office to our remote office. Our bandwidth is fine, but our latency is running around 280 ms on average to the remote office. The interesting thing is that at least 70% of the time our calls are pretty good, but often we get very odd noises and dropped calls, even though the bandwidth usage and latency appear to be running at their usual baseline. Once the problem starts it seems to persist for hours at a time. Even at times when bandwidth is [much] lower than our baseline the VoIP problem can crop up.

We're not doing any VLAN tagging (we have cheap switches/routers), so QoS is likely out of the question, although I'm not sure that will help because it appears to happen at times when we have plenty of bandwidth, so I suspect that it may have something to do with our poor latency, but then why does it work well most of the time?

I'm just puzzled as to why this works so well much of the time, but some days can become unusable. Peeking with wireshark does not show anything unusual during these bad calls, so we're a bit stumped.

Any ideas or suggestions?

Thanks...

***** Moderator's Note *****

Since there is no specification for minimum transit time in the IP specification, you're going to deal with latency on every VoIP call. Although 280 ms is a good figure, I'm at a loss to explain the dropouts if Wireshark doesn't show any anomaly.

If some party along the line is "traffic shaping" because they don't get paid for VoIP (and they want you to use the PSTN instead), that would explain the dropouts. I suggest you try encapsulating the VoIP calls in a VPN for some tests: the VPN will hide the traffic signature, so that might reveal if there's sabotage.

Hate to be cynical, but Comcast has been doing shaping for years (and denying it), so it's worth checking out. Please pass along the landing country(ies) as well: there might be some history.

Bill Horne Temporary Moderator

Please put [Telecom] at the end of your subject line, or I may never see your post! Thanks!

We have a new address for email submissions: telecomdigestmoderator atsign telecom-digest.org. This is only for those who submit posts via email: if you use a newsreader or a web interface to contribute to the digest, you don't need to change anything.

Reply to
Tom
Loading thread data ...

I'm no expert, but that figure seems high to me. Also beware of the jitter!

Reference:

formatting link

Reply to
David Quinton

Thanks for the feedback Bill...we are actually using a VPN...forgot to mention, basically running on Linux FreeSWAN.

We're just totally stumped, but your comments are helpful...thanks!

***** Moderator's Note *****

In that case, try it _without_ the VPN! Encryption adds latency, so I suggest you have some teleconferences without the VPN, and compare results.

Bill Horne Temporary Moderator

Please put [Telecom] at the end of your subject line, or I may never see your post! Thanks!

We have a new address for email submissions: telecomdigestmoderator atsign telecom-digest.org. This is only for those who submit posts via email: if you use a newsreader or a web interface to contribute to the digest, you don't need to change anything.

Reply to
Tom

For a VPN tunnel (IPsec maybe) you would need to use DSCP or type of service depending the links the traffic will flow across.

However even if you get the QoS to work (ie high priority packets overtake slower ones) the IPsec tunnel will then carefully put the packets back in the order they were injected - destroying any QoS benefit.

The fix if you run over a QoS capable network is separate tunnel per QoS - or just mark everything high priority if you mainly contend with other peoples traffic.

Jitter is much more of an issue with VoIP than absolute delay (and any packet loss above 1% is going to hurt as well).

See if you are sending big packets down the link. IPsec fragmentation and reassembly can really hurt the performance of a router doing IPsec.

Sort of depends if that is "round trip" (so inside the ITU 150 mSec 1 way recommendation), or each way.

Also the codec delays and buffers will add a fair bit to the raw latency of the traffic path, so the voice latency may be up to 50 mSec higher each way depending on the codec.

[Moderator snip]

If the phones / adaptors have good stats (eg analog voice ports on a cisco router) the equipment may tell you why things are not right.

Regards

stephen snipped-for-privacy@xyzworld.com - replace xyz with ntl

Reply to
Stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.