Start with the affected direction and media owner
Asterisk documents JITTERBUFFER() as a write-only function that adds a buffer to the read side of the channel before media reaches the Asterisk core. That scope matters: a buffer on one channel treats packets arriving on that leg; it does not repair the opposite direction, the far endpoint, a bypassed direct-media path or a queue upstream of the PBX.
Draw both call legs and record which system owns each RTP segment. Preserve channel names, SSRCs, negotiated codecs, source and destination tuples, bridge type and direct-media state. Decide where the first timing variation is observed before changing a buffer.
Choose fixed, adaptive or disabled explicitly
JITTERBUFFER(fixed) and JITTERBUFFER(adaptive) are different policies. The documented arguments are maximum size, resynchronization threshold, adaptive-only target extra and optional video synchronization; default constructs the selected implementation defaults. JITTERBUFFER(disabled) removes a buffer set by the function.
A fixed maximum or adaptive target is not a quality guarantee. More buffering can absorb timing variation but adds playout delay, while too little may leave late packets unusable. Record the exact mode and values instead of describing the call merely as buffered.
Keep dialplan and channel-driver ownership separate
The function documentation states that a jitter buffer set with JITTERBUFFER() takes priority over one requested by channel-driver configuration for that channel. Avoid stacking assumptions from a copied driver template, dialplan function, endpoint DSP and conference profile. Identify the one effective Asterisk owner and the separate endpoint behavior.
Apply the function before the media-processing point that needs dejittered input and only on the intended channel. Generated dialplan, Local channels, transfers and masquerades can change which channel executes a line; inspect the loaded dialplan and live channel rather than editing generated output or assuming the visible extension owns the RTP.
Treat ConfBridge as a specific media case
ConfBridge documents a user-profile jitterbuffer option that places the default adaptive buffer on a caller before audio mixing. It is recommended for that role but adds delay and processing cost. For fine tuning, the documentation directs operators to disable the profile option and use JITTERBUFFER() on the channel before entry.
Conference mixing, ordinary two-party bridging and direct endpoint-to-endpoint media are not interchangeable. Prove that the participant entered the expected profile and that Asterisk is in the media path before attributing an audible result to a ConfBridge buffer.
Measure transport evidence without conflating controls
CHANNEL(rtpqos,stream,field) exposes per-stream RTP and RTCP evidence including counts, local and remote jitter, packet loss and round-trip timing where available. Preserve the exact channel, stream, observation time and whether a value was locally calculated or remotely reported. An absent, zero or incomplete RTCP field is not automatic proof of a perfect path.
Asterisk QoS marking can classify outgoing signaling and media, but it does not create priority across an unmanaged network. Packet-loss concealment can synthesize missing audio only where a jitter buffer detects loss; it does not retransmit RTP or recover original speech. Buffering, QoS marking, queue policy and concealment remain separate controls.
Accept the change with latency and control calls
Use an authorized repeatable sample and compare the unmodified control with one bounded change. Record packet timing, out-of-order and loss evidence, RTP and RTCP counters, buffer mode and values, one-way delay, talker overlap, decoded audio and endpoint observations in both directions. Include a stable-network call so a change that hides one impairment but adds unacceptable latency is visible.
Revert if evidence does not show the intended improvement. Keep the smallest documented change, remove temporary tracing and preserve the previous configuration. No PBX, channel, endpoint, packet, RTP stream, buffer, network path, conference or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 JITTERBUFFER dialplan function ↗
- Asterisk 23 CHANNEL dialplan function and RTP QoS fields ↗
- Asterisk ConfBridge configuration ↗
- Asterisk IP Quality of Service ↗
- Asterisk packet-loss concealment overview ↗
- Asterisk media-experience score implementation ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.