On Thu, Nov 19, 2009 at 1:09 AM, Robert L Mathews
<lists@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!
--