Appreciate the input, Brian. I’ll definitely try to avoid setting the timer option.
In other news. I deployed The exact same FS instance (same docker container) on baremetal last night and it experiences the same issue. So, virtualization does not appear to be the problem. I just can’t figure out what else would cause this. I’m sure it’s something simple.
Hi Colin,
Depending on what you are doing with Freeswitch setting the rtp-timer
to none can produce all sorts of subtle weirdness. I would advise
against it. 2 things that I remember from our tests with this was lots
of blocked / hung calls that would build and need to be HUPed and also
carriers that would send SDP but no RTP when silence was being sent -
the call wouldn't progress through dialplan - it just got blocked
waiting on RTP>
B
On Tue, Feb 6, 2018 at 12:56 AM, Colin Morelli <colin.morelli@gmail.com> wrote:
> Hey list,
>
> I'm running FS on EC2 (I know, I know). Having some issues with random
> packet loss, which I believe almost certainly I have narrowed down to timer
> issues and/or network latency/jitter (seems surprising since I'm using
> c5.xlarge instances).
>
> Behavior is that, during a call, brief pauses or notable audio loss will
> occur. This is on high bandwidth links that are otherwise stable. Freeswitch
> logs with max debug spew out "Hot Hit 1" through "Hot Hit 10" and eventually
> "auto-flush catching up 1 packet(s)" in rapid succession (usually going
> through the cycle 4-5 times) before things settle again. Obviously that
> means a minimum of 4-5 audio packets were dropped within the span of a
> second which results in considerable audio artifacting.
>
> Changing rtp-timer-name to none, which I understand to perform synchronous
> reads of RTP audio (as opposed to timer-based async reads) makes the audio
> notably smoother. That said, I'm having a hard time uncovering the
> consequences of doing this. Obviously I understand that reads will block the
> RTP thread, but I can't seem to understand the potential ramifications of
> this. Could anyone help clarify?
>
> My other question is: assuming "timer while hot" indicates what I believe it
> does (that when the timer hit there was >1 packet in the queue to be read),
> couldn't this issue also just be caused by network jitter, and not
> necessarily just timer inconsistencies?
>
> Thanks in advance.
>
> Best,
> Colin
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> 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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
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