[Freeswitch-users] rtp-timer-name / timer issues

Tue Feb 6 15:32:00 UTC 2018

Tested again on a fresh EC2 instances (c5.xlarge) running Debian Jessie
(Kernel 3.16.0-4-amd64), since I believe that's the current recommendation,
with packages installed from the Freeswitch mainline
(version 1.6.20-37-987c9b9~64bit) and vanilla configs. I am still able to
reproduce issues where one side's audio recording drops packets that are
present in the other side. Running out of things to look at here, since I
was able to repro on baremetal as well.

On Tue, Feb 6, 2018 at 9:04 AM, Colin Morelli <colin.morelli at gmail.com>
wrote:

> Happens on all browsers.
>
> Just want to clarify my previous message, though. I had a call bridged A
> -> B (A is the WebRTC side, B the PSTN). I recorded both legs of the call
> individually. On the recording for B, B's audio is clear and smooth. On the
> recording for A, B's audio has dropped packets that correspond with the
> logs mentioned on FS. Unless I'm misunderstanding something I believe this
> should eliminate network/WebRTC/clients as being the issue.
>
> On Tue, Feb 6, 2018 at 8:45 AM, Geoff Mina <gmina at connectfirst.com> wrote:
>
>> What WebRTC client are you using? Does this happen in all browsers or
>> just one?
>>
>>
>> On Feb 6, 2018, at 5:09 AM, Colin Morelli <colin.morelli at gmail.com>
>> wrote:
>>
>> 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.
>> On Tue, Feb 6, 2018 at 3:49 AM Brian : <brians at iptel.co> wrote:
>>
>>> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20180206/f5331389/attachment-0001.html>