Tired Of Dropouts And Garbled Phone, Calls – Where To Go Next?

Home » Asterisk Users » Tired Of Dropouts And Garbled Phone, Calls – Where To Go Next?
Asterisk Users No Comments

This suggests to me that you may have congestion problems in your
“upstream” traffic flow.

Setting QoS on the packets may not help, if whatever router you are using for Internet connectivity isn’t managing the traffic flow well. In my experience, you need to do two things:

– Make sure that the traffic with QoS for low latency, is placed
in a separate transmission queue on the router from “bulk” traffic
(e.g. web service, file transfer).

– Make sure that your router uses a “traffic shaping” system, to
ensure that data isn’t being submitted to the network interface
faster than it can actually be transmitted by the *slowest*
link in the path to your Internet provider.

A lot of routers, switches, and network interface drivers these days have a lot of buffering. This is a mixed blessing. Unless you are careful, a burst of low-priority (bulk) traffic can be transmitted into your switch/router, and fill up a bunch of the buffer… by the time the system “knows” that you have some audio-QoS traffic to send, there’s a whole bunch of data ahead of it in some network router or switch (or even the ring-buffer in a network interface card) and there’s no way for your audio data to “jump ahead” of the bulk data in order to be delivered quickly.

Ideally, your system should send data upstream at a rate which never
“bursts” up to, or above your link’s sustained data transmission rate. You want the buffers in the “upstream” equipment to remain as empty as possible.

For background reading on this, look up the “Bufferbloat” problem and project, and the “Linux ultimate traffic shaper” scripts. They may not be directly applicable to your problem but may explain some of what you are seeing.

Tired Of Dropouts And Garbled Phone Calls – Where To Go Next?

Home » Asterisk Users » Tired Of Dropouts And Garbled Phone Calls – Where To Go Next?


The users in our organization are well, quite frankly, sick of phone service that is being provided. The choppy phone calls, and drop outs are detrimental to our sales force.

I’ve tried about everything I can think of.

Moved the asterisk server from VM machine to dedicated machine

More than enough bandwidth

Setting 802.1p = 7

Set Dedicated voice traffic 35% of bandwidth.

Not sure what option would be the best

Put analog lines in the conference room to avoid the dropouts – leave the sip lines in place for day to day use

Hire a consultant

Ditch the system and buy a pre-packaged system – RingCentral or some such.

There are no local asterisk professionals who can help, and we are a little leery of opening up our system to outside consultants.

Anyone else face the above, and finally abandoned Asterisk for a commercial system?

We have 167 users. I use Grandstream GXP 2100 on the desktop and Polycom ip6000 for the conference rooms.

Suggestions welcome.



16 thoughts on - Tired Of Dropouts And Garbled Phone Calls – Where To Go Next?

  • asterisk-users-bounces@lists.digium.com wrote on 10/28/2013 01:29:13 PM:


    Does the garbled audio and dropouts only occur on outside calls, or do you get them on calls between extensions? How is your phone service delivered to your site?

    If the extension to extension calls are clear, you need to be looking at your phone service and how you connect to it. If your local extensions are not clear, then you need to look at your asterisk implementation and your network.

    If your incoming circuits are delivered via SIP, are you sure you have end to end QoS between your office and your phone provider? You can set all the QoS you want on the packets as they leave your network, but if your provider isn’t honoring the QoS packets, then you can easily have audio issues. One of my locations has SIP service provided over a DSL line from the SIP provider. Just last week, the DSL line went down. We routed the calls out our standard internet connection and while it did work, we had audio dropouts (though only on incoming audio, the other end could hear us just fine). As soon as the DSL line was fixed and we routed back over their network, all the audio cleared up. It is the difference between low ping times and good QoS and higher ping times and providers who may not honor QoS.

  • I am reaching the same level of frustration. I have tried to find the source of the problems. We have IAX2 to our VoIP provider and SIP phones attached to the Asterisk – No analogue. We have a very lightly loaded 60 Mbs cable link to the Internet that tests pretty close to that most of the time.

    I have not found any good tools to track down the causes of poor voice quality. In my case, I have good incoming quality and terrible quality going out. That is, I can hear people perfectly well but they complain that my voice drops out and is garbled regardless of who places the call. As a result, I use Skype for all of my calls and if someone calls me, I
    call them back on Skype if they have any problems. I don’t understand why Skype works so well and Asterisk works so poorly on the same environment.

    Googling “Asterisk poor audio quality” return several hundred thousand references


  • Does using SIP to your ITSP make any difference? I stopped using IAX2 and switched to SIP around 2003 when I experienced similar problems, never looked back. If you insist on using IAX2, then Google for iax2 audio problems

    —–Original Message—

  • On 10/28/2013 3:59 PM, Ron Wheeler said:
    I don’t have any problems with IAX, but I hear some do.

    Bandwidth is less important than the overall quality of the internet link, latency and jitter. Either way, there is no QoS on the internet, all bets are off.

    The codec can matter too. What are you using?

    Oh, is your cable connection assymetric? Upload smaller than download? If so, that correlates to terrible audio, right?

    I’d not shoot asterisk yet. I’d focus on the internet connection and it’s components (cable modem) first.

    I use asterisk all over the place. Mostly connected to PRI’s and Carrier provided SIP trunks, with internet SIP trunks as backup. I get complaints on the Internet based SIP trunks sometimes, never on other other two.

    I’d ask most of these questions of the OP too. Overall telephony design matters.

  • Ron Wheeler писал 28.10.2013 21:59:

    good tools to track down the causes of poor voice quality. I have good incoming quality and terrible quality going out. I can hear people perfectly well but they complain that my voice drops out and is garbled regardless of who places the call.

    I had the very same problems. My users were ready to murder me.

    I’ve tried whatever I
    found relevant, and had no success. ISP was telling me that it was my problem, everything’s ok from their point of view (do they ever say opposite?).

    As a result, I’ve changed the ISP and everything became perfect. I’ve spent 2 months fighting invisible enemy, but sometimes you just have to stop trying everything possible and move to impossible options.

  • You probably need to break the problem down into more specific issues.

    Does every call suffer or is it just some?
    Is the CPU overworked at all and are calls being transcoded or all the same codec?
    Is it time of day affected?
    What load is on the network at the same time?
    Do you have monitoring tools such as smoke ping tell you the network looks so you can match to issues?
    Call drop outs suggest network issues or upset hardware, you shouldn

  • iperf is great. Another essential troubleshooting tool is nfsen/nfdump
    (or any netflow/sflow monitoring utility that shows DSCP/TOS tag values).

  • That’s a good start. Now what have you done to conclude that the Asterisk server is not the cause of your problems?

    That’s irrelevant. It’s about the quality of that bandwidth. Have you figured out if there might be a lot of packetloss or are you perhaps on a cablelink which is a *shared* medium? Once your link hits the box in the street it shares it with others who might be eating up all the bandwidth with their torrent downloads etc.? Use tools like iperf, smoke ping and mtr to see if there are obvious problems on the route to your VoIP provider.

    Once the packets leave your premises and your ISP/cable company starts messing with them a QoS setting is generally not honored so not very helpful unless your LAN is congested.

    If those analog lines are cheap, easy to get then as an intermediate solution I would order those analog lines as fast as I could. Or fix the VoIP problems, whichever is faster.

    An experienced VoIP consultant should be able to tell you what is or could be causing your problems. With your users “sick of phone service”
    it suprises me that you haven’t already hired one.

    And what if it’s your Internet link or the route to your VoIP provider?
    What if your VoIP provider is messing up?

    If you don’t want that then you don’t want that but given the state your users are in I would be less worried about giving a Consultant access to the Asterisk box and more worried about my job 🙂

    I have seen that once years ago where some clueless sales guy had totally oversold an ancient Asterisk/Bristuff/ISDN setup which was very buggy and crash prone. There was no way to make that work reliably. After the supplier failed for months I was brought in to review the setup and possibly fix it. Told the customer to cut its losses. So they kicked out their supplier and opted for a different setup.

    I don’t know how Grandstream is these days. I thought the GXP2100 was ok but I guess you already know if there’s a problem with those phones from the (lack of) intra-office call complaints from your users.

    Hire a Consultant or someone who has been part of this Community for a while and is well known on this list or in #asterisk on irc. Provide remote access if required. Change passwords afterwards.

    If you really don’t want to provide remote access then find a reputable VoIP provider with a switch physically as close as possible to your location, get a DID for a few bucks, hook it up to your Asterisk box and route it to a line on your phone, grab your cell, call that DID and see if you still have the problem. It wouldn’t be the first time that the link between you and your VoIP provider just doesn’t cut it. Or maybe your VoIP provider just sucks and you need to change to a different one. Both flowroute.com and voip.ms work well for me (no affiliation). Or maybe your Internet link sucks and you need to change your ISP.

    Good luck.

    Regards, Patrick

  • I’ve used iperf to check bandwidth before, but never looked deeper into it’s features. Thanks for the nudge. Maybe you can help me understand my results?

    This is how I usually use iperf: (ws is my ‘workstation,’ kitchen is my HTPC)

    -kitchen::sedwards:~$ iperf –server

  • Steve Edwards wrote:

    –help shows:

    Client specific:
    -b, –bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
    (default 1 Mbit/sec, implies -u)


  • ^ this

    Like others said, you really need to drill down and find out where your audio issues are. Local is easy to do, since you control the network, remote is harder.

  • I have now switched to SIP and will check the quality in the morning. G711
    Just ran a test 50 Mbps download 10Mbps upload. Should be enough I hope. Good idea. I am sure that you are right but what to test and how are not clear.

  • A general rule of thump after several years with voip

    Voip turns out to be the “canary in the coal-mine” of a network. The smallest change or problem will manifest itself as a voip issue no matter what.

    Now to some practical advice

    Voip was designed for LAN’s, The moment voip packets leave your lan and go into a WAN of any sort, it could be the source of frustration for many reasons.

    1) Lots of routers/modems are not build to handle intense voip traffic. voip generates lots of small in size UPD packages. In most of the cases the routers/modems bridging your lan with the wan have no problem handling them BUT what i have found is that once you get over a threshold of traffic its possible the routers/modem can not cope with it, mainly because the large number of packets they have to process. In most enterprise grade routers the specs give you 2 numbers for the size of data the router can handle. total throughput and pps (packets per second). Usually total throughput is calculated using a packet size of around
    1500bytes and it takes the router the same resources to process a 1500
    bytes package as it does a 90bytes packet of a g729 call, as it just looks at the headers and not the payload.So yes your router can handle
    60Mbits (of 1500byte frames) which is about 5000 packers per second but for voip that translates to less than 4Mbits of data (5000 packets of 90
    I think you can get the picture

    2) Because of 1) its possible that your ISP has issues, especially if its handling lots of voip traffic while its equipment is not optimized for that.

    3) QOS and queing in general Whatever you do with QOS to get a better priority/quality, the dirty secret is, you can only control what YOU send, not what you receive. And even that is true till your modem/router. Once the packet is gone you have no control of how it will be handle by all intermediates till it reaches its destination. You have no idea if qos is honored by ALL hops and what kind of queuing they apply (if they do) to that port/service/qos mark That beeing said, its possible that you *might* have much better luck with sip and sip rtp than with iax rtp if your isp and all its interconnects bother to offer qos for rtp. Now for receiving it can be even harder if your isp does not provide correct priority queuing for the rtp stream, as latencies can build fast especially on “busy hours” (which happen to be the same hours people use their phones the most…) where people download stuff,emails etc.

    ping.icmp and all the other networking monitoring tools/protocols could be an indicator BUT its most probable that they will be handled by the isp and its interconnects at the higher qos priority The only way to see how rtp traffic is handled is to run rtp traffic.

    The only way around this is a “dedicated circut” MPLS or similar between the points of interest (i.e offices), with specific SLA which usually means much much higher costs. Finally my 2 cents for troubleshouting. Check the network first !
    Find what triggers the problem. Is it something that happens all time regardless of traffic ?
    is it periodic ? (when bw goes over X percent, or at a specific time of day ?)
    Try different qos settings/priority queuing on the router

  • Hi there,

    Sounds like codec ptime mismatch…what codec are you using? If you are using g729 make sure that you and your provider is giving the same ptime.

  • Hi there,

    In other words you are maybe on 60ms and they are on 20ms or vice versa. Do a wireshark trace and see if the codecs and ptime agree on both sides otherwise you will get grabbled sounds.