[asterisk-bugs] [JIRA] (ASTERISK-25919) Duplicate DTMF events in ARI

[Kristan McDonald (JIRA)]

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

Kristan McDonald commented on ASTERISK-25919:
---------------------------------------------

As a workaround:
In channels.c I've added a check to prevent send_dtmf_end_event being called in the __ast_read function if the seqno of the frame is 0. This has the effect of stopping the second, duplicate tone being published into stasis.

I'm pretty certain this is definitely not the correct fix, I think it's more related to the way the DTMF is queued whilst a previous tone is being emulated, but my asterisk skills don't go as far as to be able to help there..

> Duplicate DTMF events in ARI
> ----------------------------
>
>                 Key: ASTERISK-25919
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25919
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/General
>    Affects Versions: 13.7.2, 13.8.0
>         Environment: Amazon Linux EC2 t2.micro test setup
>            Reporter: Kristan McDonald
>            Severity: Minor
>         Attachments: DTMF1.log, DTMF1.log, DTMF2.log, DTMF2.log
>
>
> Using the test node.js application code from :
> https://wiki.asterisk.org/wiki/display/AST/ARI+and+Channels%3A+Handling+DTMF
> If two DTMF tones are received close together, the second tone is sent TWICE to the ARI interface.
> RTP & DTMF logs are attached.
> See DTMF1.log for correct processing - 1 pressed on handset, 1 sent to ARI.
> See DTMF2.log for incorrect processing - 4 then 5 pressed on handset, 4, 5, 5 sent to ARI.
> Also see community support request : 
> https://community.asterisk.org/t/duplicate-dtmf-events-in-ari/66368
> I can reproduce if required.



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