Call Us Today! 877.742.2583

Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: minor fixup


The following information came from Anthony Minessale in a freeswitch-users thread:


If the jitterbuffer is already on, calling it again will just resize it, so setting it to the same is redundant, but harmless.

If you are surprised by why the jitterbuffer is paused during bridge:

If both sides of a bridge are RTP and both sides have a jb, its jitter buffer, it's fairly useless. In fact if anything, it can worsen call quality.

You should only run jitterbuffers jitter buffers at points of termination change of protocol. Examples, if FS was hosting a conference or IVR , if and you are bridging the call to a phone for instance, you don't want to not use a jitterbuffer jitter buffer because you want to preserve the original timestamps so that your phone can use its own jitterbufferjitter buffer.

For special examples applications where you are using FS jitterbuffer in front of something else that may does not have one or some other special circumstance you can use the setting chris that Chris mentioned to leave it running.

Activation instructions

The jitter buffer can be activated via channel variable, dialplan app, or sofia param.

The jitter buffer has three params that control its behavior: length, max length, and max drift. Length is the initial size of the jitter buffer in milliseconds. Max length is the upper bound for how big the jitter buffer can grow. Max drift controls how much delay the jitter buffer will tolerate before dropping frames to make up ground.

Dialplan app

Enable 60 ms jitter buffer:

Code Block
<action application="jitterbuffer" data="60"/>

Enable 60 ms jitter buffer with 200ms max length and 20 ms max drift:

Code Block
<action application="jitterbuffer" data="60:200:20"/>

Sofia profile param

This param is the initial size of the jitter buffer in milliseconds. The max length and max drift values can't be set with this param.

Code Block
<param name="auto-jitterbuffer-msec" value="60"/>


The parameter uses -hyphens- while the variable uses _underscore_

Channel Variable


Excerpt Include

Other usage


Enables/disables packet loss concealment (PLC) when using the jitter buffer. PLC is enabled by default when the jitter buffer is enabled. Set this variable before enabling the jitter buffer for it to have an effect.


Code Block
<action application="set" data="rtp_jitter_buffer_plc=true"/>

or to disable PLC:

Code Block
<action application="set" data="rtp_jitter_buffer_plc=false"/>


Enables/disables the jitter buffer during bridge.


Code Block
<action application="set" data="rtp_jitter_buffer_during_bridge=true"/>


Code Block
<action application="set" data="rtp_jitter_buffer_during_bridge=false"/>

To enable jitter buffer on only the B-leg of the call, issue commands based on these examples in this sequence:

<action application="export" data="rtp_jitter_buffer_during_bridge=true"/>
<action application="export" data="nolocal:jitterbuffer_msec=60:120"/>


The jitter buffer can be paused mid-call

Code Block
<action application="jitterbuffer" data="pause"/>


The jitter buffer can be resumed mid-call

Code Block
<action application="jitterbuffer" data="resume"/>


Jitter buffer debugging can be enabled/disabled.

Code Block
<action application="jitterbuffer" data="debug:${uuid}"/>
<action application="jitterbuffer" data="debug:off"/>


If using the Opus codec (popular with WebRTC) and the far end is sending F.E.C. (Forward Error Correction) information, you can enable a look-ahead jitter buffer in the codec configuration:

Code Block
<param name="use-jb-lookahead" value="1"/> 

On FreeSWITCH version 1.6 and later this greatly improves the audio performance even with heavy packet loss.