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

[Robert L Mathews]

I'm using FreeSWITCH 1.0.4.

When I make a call from a SIP phone to either a conference or an echo 
test on the FreeSWITCH server, the latency ("lag") starts off very low 
-- a fraction of a second. But as several minutes of time goes by, the 
lag increases. After, say, 15 minutes, the lag will reach a couple of 
seconds, making conference calls unusable.

This does not happen on pure SIP-to-SIP calls, even when FreeSWITCH is 
handling the RTP media.

If I hang up and immediately call back in (even to the same conference), 
the lag is reset to almost zero. If I put the call on "hold" and take it 
off hold, the lag is also gone.

During testing, I've found that this may be related to the freeswitch 
app on the server not getting all the CPU time it wants.

If I suspend the freeswitch process for two seconds and then resume it, 
the sound stops for two seconds, as I'd expect. But the echo/conference 
calls that were active are then lagged by two seconds until they hang up 
(or get put on hold), even after freeswitch is resumed and getting all 
the CPU time it needs.

This is easily reproduced by making a SIP call to the echo test module, 
then:

  pkill -STOP freeswitch; sleep 2; pkill -CONT freeswitch

Any echo test or conference call that was in progress will then be 
permanently lagged by two seconds. However, any SIP-to-SIP calls that 
were in progress will not become lagged.

Of course, killing it with -STOP is an artificially nasty thing to do. 
But it effectively just prevents it from being scheduled on the CPU for 
a short period of time, and I can duplicate the same behavior (more 
gradually) by just increasing the load on the machine to the point that 
the freeswitch app isn't getting much CPU time.

Just for the record, I get the same results from several different 
phones and several different Internet connections, all of which have a 
ping latency of under 40 ms to the server. This problem does not happen 
using the same phones and network connections to an asterisk server.

Throwing out an even more complicated example that I've encountered: If 
I have a SIP-to-SIP call going from party A to party B and I stop the 
process for two seconds, it doesn't permanently introduce lag to that 
call, as I mentioned. But if a third person (party C) starts 
eavesdropping on the call and presses "3" to make it a three way call, 
and then I suspend it for two seconds, the call between A and B isn't 
lagged, but what party C hears and sends *is* lagged.

Any ideas on how to fix this? Do other people see the same thing 
happening? As I said, the gradual increase in lag over a long period of 
time makes long conferences unusable, unfortunately.

-- 
Rob