[Freeswitch-users] Call latency in conferences and echo test increases over time

[Robert L Mathews]

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