Like I said,<br>The timer by default is designed to make sure that none of the audio is lost for situations like FAX etc.<br>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.<br>
<br>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.<br>
<br>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?<br><br>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. <br>
<br><br><br><br><div class="gmail_quote">On Thu, Nov 19, 2009 at 1:09 AM, Robert L Mathews <span dir="ltr"><<a href="mailto:lists@tigertech.com">lists@tigertech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Anthony Minessale wrote:<br>
<br>
> I can promise you that much of your problems will be solved with<br>
> latest SVN.<br>
<br>
</div>Okay, thanks!<br>
<br>
And in fact, I tried today's SVN, and it has fixed the problem with the<br>
conference, even without setting "rtp-autoflush". Conferences now<br>
discard packets and "catch up" when they gets behind, even with only the<br>
default "rtp-autoflush-during-bridge" set.<br>
<br>
The echo test still suffers from the same problem unless "rtp-autoflush"<br>
is used, which I assume is simply because it's not considered a bridged<br>
call.<br>
<br>
Eavesdropping on an existing bridged call, then pressing "3" to turn it<br>
into a conference call, also requires "rtp-autoflush" to avoid<br>
persistent lag on the third leg.<br>
<div class="im"><br>
<br>
> Did you answer the question about what phones? I'm going to guess Cisco<br>
> based on the symptoms.<br>
<br>
</div>It happens with all phones, as far as I can tell. I've tried at least<br>
Grandstream GXP2000, Grandstream BT102, SJPhone, Twinkle, and Express<br>
Talk (none of them Cisco). I'm fairly positive the problem is unrelated<br>
to phones; it's caused by delays in CPU scheduling of the server process.<br>
<div class="im"><br>
<br>
> non bridge calls use a timer to make sure the audio is coming in at a<br>
> steady rate to ensure bursting RTP<br>
> is played at the correct rate. Stopping it and restarting 2 seconds<br>
> later will cause a delay by design because you have suspended the<br>
> process but not the UDP stack.<br>
<br>
</div>Ummm.... well, a copy of FreeSWITCH running on any non-realtime<br>
operating system will occasionally not get scheduled for all the CPU<br>
time it wants. For example, it wouldn't be unusual for a thread to ask<br>
to sleep for 20 milliseconds but actually not wake up for 21, 25, or<br>
even 40 milliseconds because the server is busy with other things.<br>
<br>
Each time that happens, it's a smaller version of my artificial suspend<br>
test: the operating system has, of course "suspended the process but not<br>
the UDP stack". It doesn't necessarily mean there's bursty network<br>
traffic or phone timing issues.<br>
<br>
Should FreeSWITCH really lag by that much for the rest of the call? 20<br>
milliseconds here, 20 milliseconds there, and pretty soon you're talking<br>
about real seconds.<br>
<br>
I'm assuming the reason for making it catch up on bridged calls, but not<br>
non-bridged calls, is that people talking to each other can't tolerate<br>
high latency, but people listening to an IVR or something can. But is<br>
that still true if it gets seconds behind? And should the third leg of<br>
an eavesdrop-converted-to-three-way-call be considered non-bridged for<br>
this purpose?<br>
<br>
Anyway, given that current svn trunk fixes the problem by default in<br>
conferences and any other bridged call, I'm satisfied. And if anyone<br>
complains about this problem for non-bridged calls, I suppose they can<br>
enable "rtp-autoflush" to get the same "catch-up" behavior there.<br>
<br>
I took a shot at documenting these parameters in the wiki on:<br>
<a href="http://wiki.freeswitch.org/wiki/Sofia.conf.xml#rtp-autoflush-during-bridge" target="_blank">http://wiki.freeswitch.org/wiki/Sofia.conf.xml#rtp-autoflush-during-bridge</a><br>
<br>
Thanks for the help!<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Robert L Mathews, Tiger Technologies<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>