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 fairly
useless.  In fact if anything, it can worsen call quality.

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

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

On Mon, Aug 20, 2012 at 9:52 PM, mayamatakeshi <mayamatakeshi@gmail.com> wrote:
>
> On Tue, Aug 21, 2012 at 11:24 AM, Christopher Rienzo <cmrienzo@gmail.com>
> wrote:
>>
>> When you execute the jitterbuffer application, it will start the jitter
>> buffer.  The jitter buffer is paused during bridge by default and is resumed
>> when bridge ends.
>
>
> OK. Thanks.
> But this is a bit surprising. What would be the rationale for this?
> I mean, at least in the company I work for, jitterbuffer is used to solve
> problems during SIP calls. We are not so far trying to solve any problem
> with unbridged calls (like calls to voicemail) because we don't have them
> yet.
>
>>
>>  You can set sip_jitter_buffer_during_bridge=true if you want the jitter
>> buffer to keep running during bridge.
>
>
> OK. Noted.
>
>>
>>
>> It's ok to call the jitterbuffer application multiple times,
>
>
> OK.
>
>>
>> but what you described didn't make sense to me.
>
>
> Well, my doubt was if there is any problem of calling the jitterbuffer app
> multiple times. This will happen in case the channel is sent back to the
> dialplan (blind transfer) and if I don't check if the jitterbuffer was
> already set or not.
> I asked this because I saw things in the past like calling start_dtmf more
> than once causing duplication of DTMF notification (meaning more than one
> resource was allocated for the task). So I would just want to confirm this
> will not be the case for jitterbuffer. Otherwise, I would have to check if
> jitterbuffer was already called and avoid calling it again (nothing complex,
> but I will not add extra code if there is not need).
> (I would set it in the sip profile, but as the wiki says, there you cannot
> set the jitter buffer max length)
>
>>
>>  When do you want the jitter buffer on?
>
>
> Actually I want it enabled all the time no matter if the channel is bridged
> or not.
>
>>
>>  When do you want it paused?
>
>
> Never.
>
> Regards,
> takeshi
>
>>
>>
>>
>> On Mon, Aug 20, 2012 at 8:53 PM, mayamatakeshi <mayamatakeshi@gmail.com>
>> wrote:
>>>
>>> Hello,
>>> is it OK to start application jitterbuffer multiple times?
>>> For example, before bridging a call I would do this:
>>>
>>>   <action application="jitterbuffer" data="60:200:20"/>
>>>
>>>
>>>
>>>
>>> then if later the call is transferred back to the dialplan, I would call
>>> the above again before doing a new bridge.
>>> Is there any chance this to be allocating extra resources?
>>>
>>> Regards,
>>> takeshi
>>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting@freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> http://www.cudatel.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users@lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org