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

[Robert L Mathews]

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