VoIP.info Troubleshooting

Asterisk audio is choppy: jitter buffer wrong or ineffective

Find the first affected direction and RTP segment, then prove whether buffer placement, size, direct media, packet loss, latency or endpoint DSP explains the symptom.

Reviewed 2026-10-15Current Asterisk 23 JITTERBUFFER and CHANNEL API documentation plus current ConfBridge, IP QoS, packet-loss-concealment and media-experience documentation reviewed October 15, 2026; installed branch, loaded modules, channel driver, bridge topology, direct-media state, packet timing, RTCP reports, endpoint buffering, network queues, codec behavior and audible outcome remain deployment specific; no PBX, channel, endpoint, packet, RTP stream, buffer, network path, conference or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one call and the first audible defect

Capture one authorized occurrence with timestamp and timezone, linked ID and channel names, caller and destination, direction heard as choppy, bridge and direct-media state, codec, source and destination tuples, endpoint models and firmware, wired or wireless path, and the first timestamp of the defect. Preserve a short approved audio reference only under the site privacy policy.

Classify the symptom as late or uneven audio, packet loss, out-of-order delivery, robotic decoding, silence, clipping, echo or excessive conversational delay. Those symptoms can overlap but do not prove the same cause.

Prove whether Asterisk receives the affected RTP

Map both RTP directions. If direct media or another anchor bypasses Asterisk for the affected stream, an Asterisk read-side jitter buffer cannot change that segment. If Asterisk receives the stream, identify the exact channel whose read side carries the impaired direction and the point at which the dialplan or conference profile applies the buffer.

Compare packet capture, channel and SSRC evidence rather than relying on a call-detail record alone. A successful SIP dialog, answered call or populated RTP tuple does not prove steady packet timing or decoded audio.

Inspect the effective buffer rather than the intended one

Record whether the live policy is fixed, adaptive or disabled and preserve maximum size, resynchronization threshold, adaptive target extra and video-sync setting. Check for a function-set buffer, channel-driver configuration, ConfBridge user profile and endpoint DSP without assuming their labels describe one combined queue.

Because the dialplan function takes priority over a channel-driver buffer on the same channel, a copied driver value may be irrelevant. In ConfBridge, enabling the profile option selects the default adaptive behavior; fine-tuned function values require the profile option to be disabled and the function applied before bridge entry.

Compare timing, loss and delay evidence

Read the applicable CHANNEL(rtpqos,...) fields and retain the whole observation context. Compare received counts, locally calculated jitter and loss, remote RTCP reports and round-trip timing with packet-capture arrival variation and endpoint statistics. Keep missing RTCP, zero-valued fields and unsupported data distinct from measured zero impairment.

If loss is present, remember that packet-loss concealment requires a jitter buffer to identify gaps but cannot restore original packets. If arrival variation is low and decoded audio remains choppy, investigate CPU pressure, transcoding, codec mismatch, endpoint audio processing, Wi-Fi retries, virtual-host scheduling and downstream playback rather than increasing delay blindly.

Change one receive-side policy at a time

Reproduce with a stable control route, then test one bounded policy: correct the channel placement, enable one implementation, adjust one documented parameter or remove an unintended duplicate owner. Do not simultaneously change codec, QoS, direct media, endpoint firmware and buffer size; that destroys causal evidence and rollback clarity.

Measure both the impaired direction and conversational latency. A smoother waveform with unacceptable talker overlap is not a successful correction. QoS markings also require matching network policy and do not substitute for queue-capacity, congestion or wireless remediation.

Retest the failure case, control and recovery

Repeat the same approved sample across the failing path and a stable control. Compare packet timing, loss, order, RTP and RTCP fields, decoded audio, one-way delay, talker overlap and endpoint reports. Exercise transfer or conference entry only if it was part of the original symptom, then confirm an unrelated call path remains unchanged.

Keep the smallest evidenced change, document the channel and direction it affects, remove temporary tracing and retain rollback. No PBX, channel, endpoint, packet, RTP stream, buffer, network path, conference or live call was tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.