[asterisk-users] Tired of dropouts and garbled phone calls - where to go next?

Tue Oct 29 08:33:20 CDT 2013

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.

On 10/29/2013 02:49 PM, Daniel van den Berg wrote:
> 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.
>
> On 10/29/2013 11:55 AM, Stelios Koroneos wrote:
>> On Mon, 2013-10-28 at 14:29 -0400, Eddie Mikell wrote:
>>> All,
>>>
>>>
>>> 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.
>>>
>>>
>> 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
>> bytes) 
>> 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
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20131029/69be25c8/attachment.html>