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