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 _______________________________________________ FreeSWITCH-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
