[asterisk-bugs] [JIRA] (ASTERISK-25483) [patch] Built-in sounds are send at 40, 20, 40, 20ms intervals for iLBC

[Joshua Colp (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227985#comment-227985 ] 

Joshua Colp commented on ASTERISK-25483:
----------------------------------------

Copied from gerrit:

What kind of performance impact does this have on the system? Normally 20ms is what is used and if this causes a different performance profile then I'm not sure if I agree with it, since the vast majority of people are using 20ms. I've put this at -1 for now until that is explored but will re-evaluate.

> [patch] Built-in sounds are send at 40,20,40,20ms intervals for iLBC
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-25483
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25483
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Formats/General
>    Affects Versions: 11.20.0, 13.6.0
>            Reporter: Alexander Traud
>            Severity: Minor
>         Attachments: 10ms_Packetization_for_Asterisk_11.patch, 10ms_Packetization_for_Asterisk_13.patch
>
>
> For example, when you call the echo test and iLBC is negotiated as audio codec, Asterisk sends the RTP payload after 40ms, 20ms, 40ms, 20ms and so on. One would expect audio every 30ms. This creates an unnecessary delay of 10ms. Furthermore, packet-delay varies which might confuse/increase a remote jitter buffer. Because I am not aware of any real-world effects of this, I classified this issue not as major but as minor.
> As explained in ASTERISK-21492, Asterisk does not have an internal real-time clock for media but uses the source media as clock generator. In contrast to that other issue, when calling a built-in sound file (like the echo-test), Asterisk is the source of the media as well. Therefore, Asterisk is able to change behaviour.
> *Cause*
> Currently, Asterisk is reading its sound file every 20ms. Because iLBC has a default packetization time of 30ms, Asterisk has to read twice to send the first RTP packet on the wire. Then, it reads one additional chunk (20ms) and is able to create a new 30ms packet immediately. This creates this 40, 20, 40, 20. By the way, amount of samples (RTP payload) and the RTP timestamp are always 30ms. Just the real-time is 40, 20, 40 … 
> *Affected*
> Codecs with a packetization time which is not a multiple of 20ms. Therefore, iLBC 30 is affected. Furthermore, this issue occurs when non-default packetization times are configured (like sip.conf:allow=g729:10) or negotiated (like sip.conf:autoframing=yes).
> *Patch*
> The default reading was changed from 20ms to 10ms. This helps all audio codecs with increment with 10ms or 30ms, like G.729, iLBC, Speex, G.722, and G.711.
> *Remaining Limitations*
> This patch changes the default of SLN, PCM, WAV, and G.729 only, because I do not have the resources to change/test all existing formats. However, this covers all [currently downloadable formats|http://downloads.asterisk.org/pub/telephony/sounds/], except Siren (which is [not supported|https://www.digium.com/products/asterisk/downloads] in Asterisk 13 anymore) and GSM. Theoretically, Opus allows a packetization time of 5ms, even 2.5ms increments. I do not need this and therefore went for 10ms. Even with those remaining limitations, I hope this patch is useful.



--
This message was sent by Atlassian JIRA
(v6.2#6252)