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
