<br><br><div class="gmail_quote">On Tue, Aug 21, 2012 at 2:25 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the jitterbuffer is already on, calling it again will just resize<br>
it, so setting it to the same is redundant but harmless.<br>
<br>
If you are surprised by why the jitterbuffer is paused during bridge:<br>
<br>
If both sides of a bridge are RTP and both sides have a jb, its fairly<br>
useless. In fact if anything, it can worsen call quality.<br>
<br>
You should only run jitterbuffers at points of termination change of<br>
protocol. Examples, if FS was hosting a conference or IVR, if you are<br>
bridging the call to a phone for instance, you want to not use a<br>
jitterbuffer because you want to preserve the original timestamps so<br>
your phone can use its own jitterbuffer.<br></blockquote><div><br>Ah. OK. <br>But I failed to mention that I am using FS for transcoding.<br>Our rationale was this:<br> - we have terminals with bad jitter and they can select from a variety of codecs.<br>
- FS needs jitter buffers in both sides of the bridge to properly recompose the audio and do the transcoding.<br>Is this OK?<br>If yes, I understand things will not be that simple because then I need to check if transcoding is needed or not and allow for jitterbuffers to only be enabled in this case.<br>
<br>Regards,<br>takeshi<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For special examples where you are using FS jitterbuffer in front of<br>
something else that may not have one or some other special<br>
circumstance you can use the setting chris mentioned to leave it<br>
running.<br>
<div><div class="h5"><br>
<br>
<br>
On Mon, Aug 20, 2012 at 9:52 PM, mayamatakeshi <<a href="mailto:mayamatakeshi@gmail.com">mayamatakeshi@gmail.com</a>> wrote:<br>
><br>
> On Tue, Aug 21, 2012 at 11:24 AM, Christopher Rienzo <<a href="mailto:cmrienzo@gmail.com">cmrienzo@gmail.com</a>><br>
> wrote:<br>
>><br>
>> When you execute the jitterbuffer application, it will start the jitter<br>
>> buffer. The jitter buffer is paused during bridge by default and is resumed<br>
>> when bridge ends.<br>
><br>
><br>
> OK. Thanks.<br>
> But this is a bit surprising. What would be the rationale for this?<br>
> I mean, at least in the company I work for, jitterbuffer is used to solve<br>
> problems during SIP calls. We are not so far trying to solve any problem<br>
> with unbridged calls (like calls to voicemail) because we don't have them<br>
> yet.<br>
><br>
>><br>
>> You can set sip_jitter_buffer_during_bridge=true if you want the jitter<br>
>> buffer to keep running during bridge.<br>
><br>
><br>
> OK. Noted.<br>
><br>
>><br>
>><br>
>> It's ok to call the jitterbuffer application multiple times,<br>
><br>
><br>
> OK.<br>
><br>
>><br>
>> but what you described didn't make sense to me.<br>
><br>
><br>
> Well, my doubt was if there is any problem of calling the jitterbuffer app<br>
> multiple times. This will happen in case the channel is sent back to the<br>
> dialplan (blind transfer) and if I don't check if the jitterbuffer was<br>
> already set or not.<br>
> I asked this because I saw things in the past like calling start_dtmf more<br>
> than once causing duplication of DTMF notification (meaning more than one<br>
> resource was allocated for the task). So I would just want to confirm this<br>
> will not be the case for jitterbuffer. Otherwise, I would have to check if<br>
> jitterbuffer was already called and avoid calling it again (nothing complex,<br>
> but I will not add extra code if there is not need).<br>
> (I would set it in the sip profile, but as the wiki says, there you cannot<br>
> set the jitter buffer max length)<br>
><br>
>><br>
>> When do you want the jitter buffer on?<br>
><br>
><br>
> Actually I want it enabled all the time no matter if the channel is bridged<br>
> or not.<br>
><br>
>><br>
>> When do you want it paused?<br>
><br>
><br>
> Never.<br>
><br>
> Regards,<br>
> takeshi<br>
><br>
>><br>
>><br>
>><br>
>> On Mon, Aug 20, 2012 at 8:53 PM, mayamatakeshi <<a href="mailto:mayamatakeshi@gmail.com">mayamatakeshi@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hello,<br>
>>> is it OK to start application jitterbuffer multiple times?<br>
>>> For example, before bridging a call I would do this:<br>
>>><br>
>>> <action application="jitterbuffer" data="60:200:20"/><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> then if later the call is transferred back to the dialplan, I would call<br>
>>> the above again before doing a new bridge.<br>
>>> Is there any chance this to be allocating extra resources?<br>
>>><br>
>>> Regards,<br>
>>> takeshi<br>
>>><br>
>><br>
>><br>
>> _________________________________________________________________________<br>
>> Professional FreeSWITCH Consulting Services:<br>
>> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
>> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>><br>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>><br>
>> Official FreeSWITCH Sites<br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>><br>
>> FreeSWITCH-users mailing list<br>
>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>><br>
><br>
><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:<a href="tel:%2B19193869900" value="+19193869900">+19193869900</a><br>
<div class="HOEnZb"><div class="h5"><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>