> > 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. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- Asterisk-BSD mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-bsd
