[asterisk-dev] [Code Review] 3546: DTMF emulation bad calculation that hurts RTP

Petros Moisiadis ernest0x at yahoo.gr
Sat May 24 05:48:20 CDT 2014


On 05/23/2014 08:17 PM, Matthew Jordan wrote:
>
>
>
> On Sun, May 18, 2014 at 1:57 AM, Petros Moisiadis <ernest0x at yahoo.gr
> <mailto:ernest0x at yahoo.gr>> wrote:
>
>     On 05/16/2014 04:50 PM, Olle E Johansson wrote:
>>     This is an automatically generated e-mail. To reply, visit:
>>     https://reviewboard.asterisk.org/r/3546/
>>
>>
>>     Review request for Asterisk Developers.
>>     By Olle E Johansson.
>>     *Repository: * Asterisk
>>
>>
>>       Description
>>
>>     This code in channel.c is wrong. It first checks if we have a length. If not, we set it to a measured time, which is fine.
>>
>>     If we have a length and it's under the minimum DTMF duration, we set it again to the measured time. In an RTP session, the duration can be under minimum, but has no relationship to the measured time between DTMF start and end. We should keep the given RTP DTMF time and use that for emulation. I have had DTMF that was extended by up to 60 ms because of this code and that really, really broke communication for these alarm panels that send many short DTMF tones.
>>
>>     I suggest that this fix goes into 1.8 and later revisions.
>>
>>
>>       Testing
>>
>>     Hours and hours of reading DTMF logs. Countless cups of tea. A gazillion milliseconds wasted. All tested in 1.8.
>>
>>
>>       Diffs
>>
>>       * /trunk/main/channel.c (414046)
>>
>>     View Diff <https://reviewboard.asterisk.org/r/3546/diff/>
>>
>>
>>
>
>     Hello,
>
>     Could this patch help with high cpu usage issue #21872?
>
>
> Highly unlikely. The root cause of that performance problem has not
> really been found, as it has not been reproduced on a consistent basis
> by any bug marshal. This patch - at least so far - is not looking to
> address any performance problems so much as DTMF emulation extending
> digits when it shouldn't.
>
> -- 
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>

Sorry for being off-topic then, but the performance bug can be
consistently reproduced following the steps described at this comment:

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

So, if any developer has already tried these steps but did not manage to
reproduce this, it would be really helpful if he could share his
experience with a post on that issue. Perhaps it is also possible to be
given access to an environment on which this can be reproduced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140524/fdb9a81d/attachment.html>


More information about the asterisk-dev mailing list