I can promise you that much of your problems will be solved with latest SVN. There was a small change in the timer sync that was causing your symptoms in specific cases and it's been resolved for months.<br><br>Did you answer the question about what phones? I'm going to guess Cisco based on the symptoms.<br>
<br>non bridge calls use a timer to make sure the audio is coming in at a steady rate to ensure bursting RTP<br>is played at the correct rate. Stopping it and restarting 2 seconds later will cause a delay by design because you have suspended the process but not the UDP stack. If you don't want to use rtp-timer you can disable it in the profile settings for rtp-timer-name by setting it to "none" or the channel variable rtp_timer_name=none on a per call basis, this is not necessarily recommended for everyone because it's a blocking read on the rtp socket which is usually undesirable in an asynchronous thing like a phone call.<br>
<br><br>BTW,<br><br>Conference counts as a bridge because it has 2 threads one for each direction<br><br><br><br><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 3:33 PM, Robert L Mathews <span dir="ltr"><<a href="mailto:lists@tigertech.com">lists@tigertech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Anthony Minessale wrote:<br>
> Have you tried SVN trunk?<br>
<br>
</div>No, I haven't. I'll try it. (But also, if others want to try seeing if<br>
it happens, it's trivially duplicated by calling the echo test app and<br>
sending the freeswitch server process a "-STOP" signal, sleeping for a<br>
second, then sending it a "-CONT" signal.)<br>
<br>
In any case, though, I have partially found the cause of the problem --<br>
at least in the echo test module in 1.0.4. It's the same problem<br>
reported here:<br>
<br>
<a href="http://www.mail-archive.com/freeswitch-users%40lists.freeswitch.org/msg15800.html" target="_blank">http://www.mail-archive.com/freeswitch-users%40lists.freeswitch.org/msg15800.html</a><br>
<br>
The two suggestions there, explicitly setting<br>
"rtp-autoflush-during-bridge" true and "rtp_timer_name=none", didn't fix<br>
it for me. (The first is no surprise because that's the default anyway.)<br>
<br>
However, setting the (undocumented?) parameter "rtp-autoflush" to true<br>
*did* fix it in the echo test (but not the conference).<br>
<br>
I think what's happening is that FreeSWITCH contains code to detect when<br>
we've "fallen behind" the RTP audio. It looks like this happens in<br>
rtp_common_read() of switch_rtp.c: if the code detects that there are<br>
"extra" RTP packets waiting during several consecutive rtp_common_read()<br>
calls, switch_core_timer_sync() is called to catch up.<br>
<br>
This code is apparently used during bridged calls when<br>
"rtp-autoflush-during-bridge" is true (the default), which explains why<br>
I don't have the problem during SIP-to-SIP calls.<br>
<br>
However, I'm guessing that echo test calls somehow aren't considered<br>
"bridged" by that code. Therefore the code isn't being used unless<br>
"rtp-autoflush" is true.<br>
<br>
That thread suggests that this is probably a phone or network problem,<br>
but it seems to me that even if all the timing is perfect, this problem<br>
will happen if the freeswitch server thread doesn't get enough CPU time<br>
to retrieve a packet before the next one arrives. For example, if<br>
packets arrive every 20 ms but high load on the server causes the<br>
process to sleep for 25 ms, so that two packets are waiting the next<br>
time the process runs, it will never catch up that extra packet -- the<br>
echo test or conference will now be permanently 20 ms behind. And if<br>
that happens again, it will now be 40 ms behind, and so on. That<br>
explains why the lag slowly increases over time.<br>
<br>
Does that make sense? I don't quite understand why the "catch up" code<br>
isn't always used for all RTP streams: if an RTP packet poll repeatedly<br>
shows that there are extra audio packets waiting, it seems to make sense<br>
that we'd always want to catch up.<br>
<br>
Anyway, as I said, I'm still having the conference problem, even with<br>
"rtp-autoflush" enabled. So I need to try the svn trunk version and see<br>
if it still happens, then track it down further if so. I will report back.<br>
<font color="#888888"><br>
--<br>
Robert L Mathews, Tiger Technologies<br>
</font><div><div></div><div class="h5"><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><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">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">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="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>