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

[Anthony Minessale]

Have you tried SVN trunk?
1.0.4 is several months old and will soon be replaced with 1.0.5 so if you
can find similar problems on trunk it would be more helpful than possibly
pointing out issues that we have already fixed.



On Tue, Nov 17, 2009 at 4:18 PM, Robert L Mathews <lists at tigertech.com>wrote:

> 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20091118/cf37b5ba/attachment-0002.html