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 <[email protected]>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 > [email protected] > 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:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> iax:[email protected]/888 googletalk:[email protected]<googletalk%3aconf%[email protected]> pstn:213-799-1400
_______________________________________________ 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
