Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
Anthony Minessale wrote: > Like I said, > The timer by default is designed to make sure that none of the audio is > lost for situations like FAX etc. Right, that makes sense. I've updated the wiki entries I made to warn about this. > 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. Sorry for not being clear. When I said it "sleeps", I just meant "the operating system isn't scheduling any FreeSWITCH threads to run for some period of time, for whatever reason". > 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? Well, I'm using 2.4 GHz dual Xeons, but couldn't this situation happen on any hardware, if it also has non-FreeSWITCH processes consuming lots of CPU time? That's because the timer needs to make sure that rtp_common_read() is called at least once every 20 ms. If it can't be called that often, for any reason, then FreeSWITCH will fall behind the RTP stream. At that point, audio latency will certainly increase unless some of the packets are discarded. I could duplicate the latency on 1.0.4 by running many other non-FreeSWITCH processes on the same server, so that all the freeswitch threads get starved for CPU time. FreeSWITCH then can't read the RTP packets as fast as they come in, and since the 1.0.4 code didn't flush those extra packets in conferences, that caused noticeable latency. Imposing heavy server load is obviously a silly thing to do, but something similar could happen on any server that fires up lots of non-FreeSWITCH, CPU-hungry processes. (In my case it was virus scanners.) Not using a dedicated server is also silly if people care about call quality, but I was just initially using it for conferences, and I didn't care if some packets were dropped. But conference packet dropping didn't happen on 1.0.4. Instead, a noticeable lag developed, which I did care about. Since 1.0.5 *does* work the way I expect in conferences and other bridged calls (discarding packets), I'm *definitely* not complaining -- please consider this a resolved issue! I agree that it makes sense to preserve all packets for some RTP streams such as faxes and DTMF recognition, and basing that decision on whether the call is bridged makes as much sense as anything else I can think of (although perhaps that flag isn't getting set properly for the third leg of eavesdrop-converted-to-three-way calls). I've been impressed by the extremely high performance of FreeSWITCH. The conference latency I was hearing in 1.0.4 was caused by the fact that I'm stressing the server with separate, unrelated processes, which is a foolish thing to do if you care about audio quality. I was just hoping that FreeSWITCH could more gracefully deal with such foolishness in cases where people *don't* care about audio quality... and 1.0.5 does. That's perfect. Thanks again! -- Robert L Mathews, Tiger Technologies ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
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 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 > FreeSWITCH-users@lists.freeswitch.org > 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:anthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org iax:gu...@conference.freeswitch.or
Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
I can promise you that much of your problems will be solved with latest SVN. There was a small change in the timer sync that was causing your symptoms in specific cases and it's been resolved for months. Did you answer the question about what phones? I'm going to guess Cisco based on the symptoms. 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. If you don't want to use rtp-timer you can disable it in the profile settings for rtp-timer-name by setting it to "none" or the channel variable rtp_timer_name=none on a per call basis, this is not necessarily recommended for everyone because it's a blocking read on the rtp socket which is usually undesirable in an asynchronous thing like a phone call. BTW, Conference counts as a bridge because it has 2 threads one for each direction On Wed, Nov 18, 2009 at 3:33 PM, Robert L Mathews wrote: > Anthony Minessale wrote: > > Have you tried SVN trunk? > > No, I haven't. I'll try it. (But also, if others want to try seeing if > it happens, it's trivially duplicated by calling the echo test app and > sending the freeswitch server process a "-STOP" signal, sleeping for a > second, then sending it a "-CONT" signal.) > > In any case, though, I have partially found the cause of the problem -- > at least in the echo test module in 1.0.4. It's the same problem > reported here: > > > http://www.mail-archive.com/freeswitch-users%40lists.freeswitch.org/msg15800.html > > The two suggestions there, explicitly setting > "rtp-autoflush-during-bridge" true and "rtp_timer_name=none", didn't fix > it for me. (The first is no surprise because that's the default anyway.) > > However, setting the (undocumented?) parameter "rtp-autoflush" to true > *did* fix it in the echo test (but not the conference). > > I think what's happening is that FreeSWITCH contains code to detect when > we've "fallen behind" the RTP audio. It looks like this happens in > rtp_common_read() of switch_rtp.c: if the code detects that there are > "extra" RTP packets waiting during several consecutive rtp_common_read() > calls, switch_core_timer_sync() is called to catch up. > > This code is apparently used during bridged calls when > "rtp-autoflush-during-bridge" is true (the default), which explains why > I don't have the problem during SIP-to-SIP calls. > > However, I'm guessing that echo test calls somehow aren't considered > "bridged" by that code. Therefore the code isn't being used unless > "rtp-autoflush" is true. > > That thread suggests that this is probably a phone or network problem, > but it seems to me that even if all the timing is perfect, this problem > will happen if the freeswitch server thread doesn't get enough CPU time > to retrieve a packet before the next one arrives. For example, if > packets arrive every 20 ms but high load on the server causes the > process to sleep for 25 ms, so that two packets are waiting the next > time the process runs, it will never catch up that extra packet -- the > echo test or conference will now be permanently 20 ms behind. And if > that happens again, it will now be 40 ms behind, and so on. That > explains why the lag slowly increases over time. > > Does that make sense? I don't quite understand why the "catch up" code > isn't always used for all RTP streams: if an RTP packet poll repeatedly > shows that there are extra audio packets waiting, it seems to make sense > that we'd always want to catch up. > > Anyway, as I said, I'm still having the conference problem, even with > "rtp-autoflush" enabled. So I need to try the svn trunk version and see > if it still happens, then track it down further if so. I will report back. > > -- > Robert L Mathews, Tiger Technologies > > ___ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > 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:anthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.org pstn:213-799-1400 ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
Anthony Minessale wrote: > Have you tried SVN trunk? No, I haven't. I'll try it. (But also, if others want to try seeing if it happens, it's trivially duplicated by calling the echo test app and sending the freeswitch server process a "-STOP" signal, sleeping for a second, then sending it a "-CONT" signal.) In any case, though, I have partially found the cause of the problem -- at least in the echo test module in 1.0.4. It's the same problem reported here: http://www.mail-archive.com/freeswitch-users%40lists.freeswitch.org/msg15800.html The two suggestions there, explicitly setting "rtp-autoflush-during-bridge" true and "rtp_timer_name=none", didn't fix it for me. (The first is no surprise because that's the default anyway.) However, setting the (undocumented?) parameter "rtp-autoflush" to true *did* fix it in the echo test (but not the conference). I think what's happening is that FreeSWITCH contains code to detect when we've "fallen behind" the RTP audio. It looks like this happens in rtp_common_read() of switch_rtp.c: if the code detects that there are "extra" RTP packets waiting during several consecutive rtp_common_read() calls, switch_core_timer_sync() is called to catch up. This code is apparently used during bridged calls when "rtp-autoflush-during-bridge" is true (the default), which explains why I don't have the problem during SIP-to-SIP calls. However, I'm guessing that echo test calls somehow aren't considered "bridged" by that code. Therefore the code isn't being used unless "rtp-autoflush" is true. That thread suggests that this is probably a phone or network problem, but it seems to me that even if all the timing is perfect, this problem will happen if the freeswitch server thread doesn't get enough CPU time to retrieve a packet before the next one arrives. For example, if packets arrive every 20 ms but high load on the server causes the process to sleep for 25 ms, so that two packets are waiting the next time the process runs, it will never catch up that extra packet -- the echo test or conference will now be permanently 20 ms behind. And if that happens again, it will now be 40 ms behind, and so on. That explains why the lag slowly increases over time. Does that make sense? I don't quite understand why the "catch up" code isn't always used for all RTP streams: if an RTP packet poll repeatedly shows that there are extra audio packets waiting, it seems to make sense that we'd always want to catch up. Anyway, as I said, I'm still having the conference problem, even with "rtp-autoflush" enabled. So I need to try the svn trunk version and see if it still happens, then track it down further if so. I will report back. -- Robert L Mathews, Tiger Technologies ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
Have you tried SVN trunk?
1.0.4 is several months old and will soon be replaced with 1.0.5 so if you
can find similar problems on trunk it would be more helpful than possibly
pointing out issues that we have already fixed.
On Tue, Nov 17, 2009 at 4:18 PM, Robert L Mathews wrote:
> I'm using FreeSWITCH 1.0.4.
>
> When I make a call from a SIP phone to either a conference or an echo
> test on the FreeSWITCH server, the latency ("lag") starts off very low
> -- a fraction of a second. But as several minutes of time goes by, the
> lag increases. After, say, 15 minutes, the lag will reach a couple of
> seconds, making conference calls unusable.
>
> This does not happen on pure SIP-to-SIP calls, even when FreeSWITCH is
> handling the RTP media.
>
> If I hang up and immediately call back in (even to the same conference),
> the lag is reset to almost zero. If I put the call on "hold" and take it
> off hold, the lag is also gone.
>
> During testing, I've found that this may be related to the freeswitch
> app on the server not getting all the CPU time it wants.
>
> If I suspend the freeswitch process for two seconds and then resume it,
> the sound stops for two seconds, as I'd expect. But the echo/conference
> calls that were active are then lagged by two seconds until they hang up
> (or get put on hold), even after freeswitch is resumed and getting all
> the CPU time it needs.
>
> This is easily reproduced by making a SIP call to the echo test module,
> then:
>
> pkill -STOP freeswitch; sleep 2; pkill -CONT freeswitch
>
> Any echo test or conference call that was in progress will then be
> permanently lagged by two seconds. However, any SIP-to-SIP calls that
> were in progress will not become lagged.
>
> Of course, killing it with -STOP is an artificially nasty thing to do.
> But it effectively just prevents it from being scheduled on the CPU for
> a short period of time, and I can duplicate the same behavior (more
> gradually) by just increasing the load on the machine to the point that
> the freeswitch app isn't getting much CPU time.
>
> Just for the record, I get the same results from several different
> phones and several different Internet connections, all of which have a
> ping latency of under 40 ms to the server. This problem does not happen
> using the same phones and network connections to an asterisk server.
>
> Throwing out an even more complicated example that I've encountered: If
> I have a SIP-to-SIP call going from party A to party B and I stop the
> process for two seconds, it doesn't permanently introduce lag to that
> call, as I mentioned. But if a third person (party C) starts
> eavesdropping on the call and presses "3" to make it a three way call,
> and then I suspend it for two seconds, the call between A and B isn't
> lagged, but what party C hears and sends *is* lagged.
>
> Any ideas on how to fix this? Do other people see the same thing
> happening? As I said, the gradual increase in lag over a long period of
> time makes long conferences unusable, unfortunately.
>
> --
> Rob
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> 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:anthony_miness...@hotmail.com
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] Call latency in conferences and echo test increases over time
Can you tell us what kind of phone you're using? And have you tried
this on SVN trunk?
/b
On Nov 17, 2009, at 4:18 PM, Robert L Mathews wrote:
> I'm using FreeSWITCH 1.0.4.
>
> When I make a call from a SIP phone to either a conference or an echo
> test on the FreeSWITCH server, the latency ("lag") starts off very low
> -- a fraction of a second. But as several minutes of time goes by,
> the
> lag increases. After, say, 15 minutes, the lag will reach a couple of
> seconds, making conference calls unusable.
>
> This does not happen on pure SIP-to-SIP calls, even when FreeSWITCH is
> handling the RTP media.
>
> If I hang up and immediately call back in (even to the same
> conference),
> the lag is reset to almost zero. If I put the call on "hold" and
> take it
> off hold, the lag is also gone.
>
> During testing, I've found that this may be related to the freeswitch
> app on the server not getting all the CPU time it wants.
>
> If I suspend the freeswitch process for two seconds and then resume
> it,
> the sound stops for two seconds, as I'd expect. But the echo/
> conference
> calls that were active are then lagged by two seconds until they
> hang up
> (or get put on hold), even after freeswitch is resumed and getting all
> the CPU time it needs.
>
> This is easily reproduced by making a SIP call to the echo test
> module,
> then:
>
> pkill -STOP freeswitch; sleep 2; pkill -CONT freeswitch
>
> Any echo test or conference call that was in progress will then be
> permanently lagged by two seconds. However, any SIP-to-SIP calls that
> were in progress will not become lagged.
>
> Of course, killing it with -STOP is an artificially nasty thing to do.
> But it effectively just prevents it from being scheduled on the CPU
> for
> a short period of time, and I can duplicate the same behavior (more
> gradually) by just increasing the load on the machine to the point
> that
> the freeswitch app isn't getting much CPU time.
>
> Just for the record, I get the same results from several different
> phones and several different Internet connections, all of which have a
> ping latency of under 40 ms to the server. This problem does not
> happen
> using the same phones and network connections to an asterisk server.
>
> Throwing out an even more complicated example that I've encountered:
> If
> I have a SIP-to-SIP call going from party A to party B and I stop the
> process for two seconds, it doesn't permanently introduce lag to that
> call, as I mentioned. But if a third person (party C) starts
> eavesdropping on the call and presses "3" to make it a three way call,
> and then I suspend it for two seconds, the call between A and B isn't
> lagged, but what party C hears and sends *is* lagged.
>
> Any ideas on how to fix this? Do other people see the same thing
> happening? As I said, the gradual increase in lag over a long period
> of
> time makes long conferences unusable, unfortunately.
>
> --
> Rob
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-
> users
> http://www.freeswitch.org
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
[Freeswitch-users] Call latency in conferences and echo test increases over time
I'm using FreeSWITCH 1.0.4.
When I make a call from a SIP phone to either a conference or an echo
test on the FreeSWITCH server, the latency ("lag") starts off very low
-- a fraction of a second. But as several minutes of time goes by, the
lag increases. After, say, 15 minutes, the lag will reach a couple of
seconds, making conference calls unusable.
This does not happen on pure SIP-to-SIP calls, even when FreeSWITCH is
handling the RTP media.
If I hang up and immediately call back in (even to the same conference),
the lag is reset to almost zero. If I put the call on "hold" and take it
off hold, the lag is also gone.
During testing, I've found that this may be related to the freeswitch
app on the server not getting all the CPU time it wants.
If I suspend the freeswitch process for two seconds and then resume it,
the sound stops for two seconds, as I'd expect. But the echo/conference
calls that were active are then lagged by two seconds until they hang up
(or get put on hold), even after freeswitch is resumed and getting all
the CPU time it needs.
This is easily reproduced by making a SIP call to the echo test module,
then:
pkill -STOP freeswitch; sleep 2; pkill -CONT freeswitch
Any echo test or conference call that was in progress will then be
permanently lagged by two seconds. However, any SIP-to-SIP calls that
were in progress will not become lagged.
Of course, killing it with -STOP is an artificially nasty thing to do.
But it effectively just prevents it from being scheduled on the CPU for
a short period of time, and I can duplicate the same behavior (more
gradually) by just increasing the load on the machine to the point that
the freeswitch app isn't getting much CPU time.
Just for the record, I get the same results from several different
phones and several different Internet connections, all of which have a
ping latency of under 40 ms to the server. This problem does not happen
using the same phones and network connections to an asterisk server.
Throwing out an even more complicated example that I've encountered: If
I have a SIP-to-SIP call going from party A to party B and I stop the
process for two seconds, it doesn't permanently introduce lag to that
call, as I mentioned. But if a third person (party C) starts
eavesdropping on the call and presses "3" to make it a three way call,
and then I suspend it for two seconds, the call between A and B isn't
lagged, but what party C hears and sends *is* lagged.
Any ideas on how to fix this? Do other people see the same thing
happening? As I said, the gradual increase in lag over a long period of
time makes long conferences unusable, unfortunately.
--
Rob
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
