[Asterisk-bsd] MeetMe drift

[David G Lawrence]

> >    Attached is a patch to Asterisk's channel.c that limits the queue
> > depth of voice frames to a maximum of just 2 frames (40ms) on the channel
> > input queue. Under certain circumstances, this may result in an occasional
> > dropped voice frame, but that is better in my opinion than adding extra
> > latency to the call.
> 
> Some reports of audio quality problems coming in from the AskoziaPBX
> community seem to incriminate this patch. When this occurs on IAX
> channels, enabling / increasing the jitterbuffer seems to help which
> leads me to a dropped frame issue.
> 
> This makes sense as these systems are usually low-power embedded or
> SBC systems. Removing this patch from my build process should take
> care of the problem but I really like the idea of such a patch
> providing tangible feedback when the system's limits have been
> exceeded instead of merely increasing delay infinitely.
> 
> My question, do you have a recommended higher value for this queue
> limit? I was thinking of setting it to 5 frames. This would be roughly
> 100ms which, in a round-trip situation would lead to a maximum of
> 200ms of delay being contributed to the call. This is, as I understand
> it, the theoretical limit in delay that a call can have before its
> participants are unable to coordinate their conversation.
> 
> Thoughts?
> 
> Once again, thanks for contributing and providing insight into these issues!

   I guess people have different sensitivities - for me, delays in a
conversation really saps the energy out of a call by reducing the
interactivity of the conversation and causing people to interrupt
each other. These things are far more annoying to me than an occasional
blip in the audio stream caused by a dropped packet. If packet loss
gets so bad that you are having trouble understanding the other person,
then perhaps that is another matter, but then I think the right solution
is to upgrade the VoIP server hardware or change VoIP service providers
(if that is how you connect to the PSTN).
   When trying to calculate how many frames of buffering is acceptable,
keep in mind that this adds to delay that will come from other causes.
Most VoIP hard phones, for example, have their own internal buffering
which is often 100ms or more. I've used soft phones that had 200ms of
internal delay. Plus you have delays through the Internet or PSTN
(whichever the case may be) that will likely add another 75ms. So you
get something like: 100 * 2 + 75 = 275ms as a baseline. If you then
add Asterisk queue delays of 100ms * 2, you're now at 475ms. A half second
is pretty annoying.
   I use Cisco hard phones here and these have an internal delay of about
65ms (depends on model and protocol). I connect to the PSTN via two
ISDN-BRI (4 channels total) provided through an Adtran Atlas 550 TDM
switch which converts these to T1 which is then connected to an Asterisk
server by way of a Sangoma T1 card. This keeps latency to a few
milliseconds to the PSTN and for local calls the total call latency is
typically 85-105ms, with US long distance calls a bit worse at 120-150ms
total. Asterisk queueing doesn't come into play here since the packets
are only being routed to the hard phone. When Asterisk is an endpoint,
such as the case of a conference call, then of course those queue delays
will add to the total.
   In my setup here, I never have dropped packets. ...but then I've
carefully chosen this solution for quality and tuned the system carefully.
   I think the proper solution is to make the queue limit a tunable
parameter so that people can set it to an appropriate value for their
individual circumstance. I think a reasonable value would be in the
2-6 frames range, but I can imagine that some people may be doing VoIP over
an unstable Internet with wild swings in RTT that will require more
buffering.
   BTW, I think the patch I submitted actually provides for a queue depth
of 3 - two existing frames plus a third, so the delay will range from
40-60ms, depending on how things line up timing wise.

-DG

David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.