Audio
"Exceptionally long voice queue length" in Asterisk
This warning is about media, not signalling. Frames are arriving faster than they are being written out, and callers hear the result as choppy, robotic, or increasingly delayed audio.
What it looks like in the log
[2026-08-17 17:21:38] WARNING[26610][C-00004112] channel.c: Exceptionally long voice queue length queuing to PJSIP/1007-000029abWhat it means
Asterisk moves audio in small frames on a strict schedule. When something prevents a frame being written on time, the next one queues behind it. Once the backlog passes a threshold, this warning appears.
Left alone, the backlog grows. The call does not drop, which is what makes this insidious: signalling looks perfect, the call stays up, and the audio quality degrades throughout.
Most common causes
-
01CPU saturation on the box
Transcoding is expensive. A box doing G.729 to ulaw conversion on more calls than it has cycles for produces this across many channels at once.
-
02Disk I/O blocking the media path
Recording every call to slow storage, or a log rotating onto a busy disk, can stall the thread long enough to back up the queue.
-
03Network jitter on one leg
If the warning is isolated to one channel or one trunk, the path to that peer is the suspect rather than the system.
-
04A virtual machine being starved
Steal time on an oversubscribed hypervisor produces exactly this pattern with no visible local load, which makes it hard to find from inside the guest.
-
05An overloaded conference or bridge
Mixing many participants concentrates work on one thread, so a large conference can back up while the rest of the system is idle.
How to tell which one it is
Count how many distinct channels the warning fires on. Many channels at the same moment points at the system - CPU, disk, or the hypervisor. A single channel repeatedly points at that leg's network path.
Then correlate the timestamps against load on the box. If the warnings cluster at busy hour, capacity is the answer; if they are spread evenly, look at the path instead.
How to fix it
-
Reduce transcoding
Aligning codecs end to end so Asterisk can pass through rather than convert removes the largest single CPU cost on most systems.
-
Move recordings off the media path
Write recordings to fast local storage and ship them elsewhere afterwards, rather than recording directly to a network mount.
-
Check for steal time on virtualised hosts
High steal with low guest load means the problem is outside the VM and no local tuning will fix it.
-
Investigate the single-leg case as a network problem
When it is one trunk, capture the path and look for jitter and loss rather than adjusting the PBX.