Packet loss - strategies for dealing with

I have recently installed Asterisk using the FreePBX linux distribution. I am running Asterisk 1.2.9.1 on a dual-core Pentium 4 with 512M RAM and RAID 1 disks - a Dell PowerEdge 850 rackmount server to be specific. The machine is behind a Cisco 2821 router which is connected to a 2 mbps symmetric Internet connection. This is co-located at our ISP.

Asterisk is trunked to Broadvoice and to a Cisco Call Manager Express and we are preparing to deploy Sipura SPA-3000 units to remote users. The intention is to allow users to call each other and to the Call Manager.

I have been trying to get Asterisk to provide decent call quality over the Internet but am having a lot of problems with packet loss. When I’m calling on the same LAN as Asterisk, the quality is fine, but as soon as I connect the SPA3000 to another ISP (a 1mbps cable modem), I start getting significant packet loss.

I have tried a number of codecs: g.711 ulaw (the native call manager codec), g.729 (not free but worth trying), and g.726. I have also tried GSM through X-Lite just to test. All have significant voice problems due to packet loss, even when there is no transcoding occurring.

I’m at a bit of a loss here. I should have plenty of bandwidth for those codecs and some (GSM in particular) are very frugal. Yet I still get packet loss.

What should I be focusing on beyond codec changes? I have exhausted that option at this point, as I’ve tried all the codecs that the SPA3000 supports.

i would say that this indicates more of a network issue than an asterisk issue.

the server at your ISP - i’m assuming it’s firewalled, and, if so, have they opened the necessary ports that asterisk requires (you’d be using SIP with the sipura’s and xlite)??? that COULD be a part of the problem, but normally you’d not get any audio if there are firewall issues.

have you tested the network connection between your location and your ISP to check for packet loss outside of asterisk? if audio on your local LAN is fine, then that would indicate to me that either your ISP or your cable provider is having issues.

sorry i can’t help more, but there are about 1600 variables you’ll need to test - i’d start by load testing your network connections on both ends and see if you can’t find any patterns.

good luck.

Thanks for the quick response. I’ve been testing the connection and have been seeing similar packet loss through ping. This leads me to believe it is a network problem also, as you point out.

So the question then is, any suggestions on how to debug this within Linux or a pointer to a group that I could ask this question to?

the only thing i can suggest is attempting to ping from each box, to see if you can isolate which side the problem is on. you might try throwing a new NIC in whatever box is causing you issues and/or attempting to update the drivers.

past that, i really can’t help you much, other than saying that ‘ethtool’ is a good tool for determining the basics of your network connection.

good luck and let us know if you run into issues…i’m sure somone here is much smarter than i am when it comes to networking.

[quote=“matt.hocker”]Thanks for the quick response. I’ve been testing the connection and have been seeing similar packet loss through ping. This leads me to believe it is a network problem also, as you point out.

So the question then is, any suggestions on how to debug this within Linux or a pointer to a group that I could ask this question to?[/quote]

Ping won’t necessarily tell you if there is packet loss between you and the other location. ICMP packets do not have the same priority on routers as TCP or UDP packets. However, it is a good indicator. Your ear is a good measuring device. If the sound quality is bad, you are likely dropping packets. The can be on your upstream connection or anywhere inbetween.

You might try implementing QoS on your Cisco router and apply it to your upstream connection. That way you’ll know that at least your voice packets are making it to your provider’s network with precedence. A traceroute between both sites will tell you where the slowdowns are occurring with the ICMP caveat listed above.

Your Cable Providor is probably using a caching server to improve performance. Your packet loss could be related to how they are providing the image of high speed without having highspeed. In the dark days of early cable internet it was common for the cable company to serve an entire neighbor hood with a 128KB ISDN connection and a caching server.

I’ve rebooted the server and the ping packet loss has been eliminated (it was 5% before) and some packet loss has improved on the SIP connection but it’s still ‘scratchy’.

I’m not sure I believe that caching would ever be done on UDP packets - they tend to be time-sensitive (a cached UDP packet would be largely unusable) so I don’t think that’s the issue.

I’m wondering if Ethernet drivers have any effect? I just let CentOS (TrixBox’s distro of choice) detect the Ethernet controller, which it appeared to do just fine.

Or could it be that there are two ethernet ports on this computer? Does Asterisk get confused with such a configuration?

Asterisk doesn’t know about ethernet ports - it just sends stuff our via IP.

My point wasn’t that your UDP packets would be cached. The point was find out how fat their pipe really is and how many customers are using the pipe.

Your improvement after rebooting, was that an immediate improvement? What time of day do you see the worst packet loss, etc. Start thinking about what could be on your network or on their network that might cause packet loss. Put Ethereal on your network and see what traffic is there.