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

[Anthony Minessale]

Like I said,
The timer by default is designed to make sure that none of the audio is lost
for situations like FAX etc.
There are parameters you can  configure to disable the timers that I
mentioned in the last email which will cause all of the audio to be jammed
into your ear like twiddlebugs if you did you sleep test and brought it
back.

We do not use sleep for the timers we have timer objects into the code
derived from a high priority thread sending conditional broadcasts to the
timer objects.  There is certainly a place where this can begin to break
down but it has proven to provide reliable timing to thousands of concurrent
channels.  The auto-flush can get false positives in jittery situations is
not always the best answer.

What kind of CPU are you using and what kind of hardware that you suspect
you are getting delayed cpu scheduling on a small number of calls?

I appreciate your theory and I am willing to investigate a little for you
but you must be aware we have put more than a few hours of thought into the
architecture here.  There may be a bigger problem with the eavesdropping
which we can have a look at today because that does not sound right.




On Thu, Nov 19, 2009 at 1:09 AM, Robert L Mathews <lists at tigertech.com>wrote:

> Anthony Minessale wrote:
>
> > I can promise you that much of your problems will be solved with
> > latest SVN.
>
> Okay, thanks!
>
> And in fact, I tried today's SVN, and it has fixed the problem with the
> conference, even without setting "rtp-autoflush". Conferences now
> discard packets and "catch up" when they gets behind, even with only the
> default "rtp-autoflush-during-bridge" set.
>
> The echo test still suffers from the same problem unless "rtp-autoflush"
> is used, which I assume is simply because it's not considered a bridged
> call.
>
> Eavesdropping on an existing bridged call, then pressing "3" to turn it
> into a conference call, also requires "rtp-autoflush" to avoid
> persistent lag on the third leg.
>
>
> > Did you answer the question about what phones?  I'm going to guess Cisco
> > based on the symptoms.
>
> It happens with all phones, as far as I can tell. I've tried  at least
> Grandstream GXP2000, Grandstream BT102, SJPhone, Twinkle, and Express
> Talk (none of them Cisco). I'm fairly positive the problem is unrelated
> to phones; it's caused by delays in CPU scheduling of the server process.
>
>
> > non bridge calls use a timer to make sure the audio is coming in at a
> > steady rate to ensure bursting RTP
> > is played at the correct rate.  Stopping it and restarting 2 seconds
> > later will cause a delay by design because you have suspended the
> > process but not the UDP stack.
>
> Ummm.... well, a copy of FreeSWITCH running on any non-realtime
> operating system will occasionally not get scheduled for all the CPU
> time it wants. For example, it wouldn't be unusual for a thread to ask
> to sleep for 20 milliseconds but actually not wake up for 21, 25, or
> even 40 milliseconds because the server is busy with other things.
>
> Each time that happens, it's a smaller version of my artificial suspend
> test: the operating system has, of course "suspended the process but not
> the UDP stack". It doesn't necessarily mean there's bursty network
> traffic or phone timing issues.
>
> Should FreeSWITCH really lag by that much for the rest of the call? 20
> milliseconds here, 20 milliseconds there, and pretty soon you're talking
> about real seconds.
>
> I'm assuming the reason for making it catch up on bridged calls, but not
> non-bridged calls, is that people talking to each other can't tolerate
> high latency, but people listening to an IVR or something can. But is
> that still true if it gets seconds behind? And should the third leg of
> an eavesdrop-converted-to-three-way-call be considered non-bridged for
> this purpose?
>
> Anyway, given that current svn trunk fixes the problem by default in
> conferences and any other bridged call, I'm satisfied. And if anyone
> complains about this problem for non-bridged calls, I suppose they can
> enable "rtp-autoflush" to get the same "catch-up" behavior there.
>
> I took a shot at documenting these parameters in the wiki on:
>
> http://wiki.freeswitch.org/wiki/Sofia.conf.xml#rtp-autoflush-during-bridge
>
> Thanks for the help!
>
> --
> Robert L Mathews, Tiger Technologies
>
> _______________________________________________
> 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/20091119/2d51c0cc/attachment-0002.html