On Wed, Nov 18, 2009 at 3:33 PM, Robert L Mathews
<lists@tigertech.com> wrote:
Anthony Minessale wrote:
> Have you tried SVN trunk?
No, I haven't. I'll try it. (But also, if others want to try seeing if
it happens, it's trivially duplicated by calling the echo test app and
sending the freeswitch server process a "-STOP" signal, sleeping for a
second, then sending it a "-CONT" signal.)
In any case, though, I have partially found the cause of the problem --
at least in the echo test module in 1.0.4. It's the same problem
reported here:
http://www.mail-archive.com/freeswitch-users%40lists.freeswitch.org/msg15800.html
The two suggestions there, explicitly setting
"rtp-autoflush-during-bridge" true and "rtp_timer_name=none", didn't fix
it for me. (The first is no surprise because that's the default anyway.)
However, setting the (undocumented?) parameter "rtp-autoflush" to true
*did* fix it in the echo test (but not the conference).
I think what's happening is that FreeSWITCH contains code to detect when
we've "fallen behind" the RTP audio. It looks like this happens in
rtp_common_read() of switch_rtp.c: if the code detects that there are
"extra" RTP packets waiting during several consecutive rtp_common_read()
calls, switch_core_timer_sync() is called to catch up.
This code is apparently used during bridged calls when
"rtp-autoflush-during-bridge" is true (the default), which explains why
I don't have the problem during SIP-to-SIP calls.
However, I'm guessing that echo test calls somehow aren't considered
"bridged" by that code. Therefore the code isn't being used unless
"rtp-autoflush" is true.
That thread suggests that this is probably a phone or network problem,
but it seems to me that even if all the timing is perfect, this problem
will happen if the freeswitch server thread doesn't get enough CPU time
to retrieve a packet before the next one arrives. For example, if
packets arrive every 20 ms but high load on the server causes the
process to sleep for 25 ms, so that two packets are waiting the next
time the process runs, it will never catch up that extra packet -- the
echo test or conference will now be permanently 20 ms behind. And if
that happens again, it will now be 40 ms behind, and so on. That
explains why the lag slowly increases over time.
Does that make sense? I don't quite understand why the "catch up" code
isn't always used for all RTP streams: if an RTP packet poll repeatedly
shows that there are extra audio packets waiting, it seems to make sense
that we'd always want to catch up.
Anyway, as I said, I'm still having the conference problem, even with
"rtp-autoflush" enabled. So I need to try the svn trunk version and see
if it still happens, then track it down further if so. I will report back.
--
Robert L Mathews, Tiger Technologies