[asterisk-bugs] [JIRA] (ASTERISK-29329) app_dial: DTMF to 'D' option gets duplicated if there are multiple progress events

[N A (JIRA)]

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

N A commented on ASTERISK-29329:
--------------------------------

That fixed the bug for me! I read every line of the patch four times and I don't see a difference between the original and the changed, but applying the patch did the trick. I tested a case that failed, restarted after recompiling, and now it works as expected. Looks good to merge into master - thanks!

> app_dial: DTMF to 'D' option gets duplicated if there are multiple progress events
> ----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29329
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29329
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_dial
>    Affects Versions: 18.2.0
>         Environment: Debian 10
>            Reporter: N A
>            Assignee: N A
>            Severity: Major
>              Labels: patch
>         Attachments: 0001-app_dial.c-Only-send-DTMF-on-first-progress-event.patch
>
>
> It seems that the D (DTMF) option for the Dial() application does not keep track of whether or not DTMF is sent. The result is that if multiple progress events are passed through before the call is answered, the DTMF string will get sent multiple times, causing a lot of confusion since the caller doesn't hear anything until the DTMF is finished getting sent multiple times.
> I first figured this out when I was getting no audio as the caller. I called myself and answered the phone. Instead of hearing audio, I heard DTMF, which narrowed the issue down to this:
> For example, the below are both from the same unanswered call:
> [Mar  4 15:54:13]     -- Local/82311125 at test-dest-00000022;1 is making progress passing it to SIP/ATAxLA2-0000000b
> [Mar  4 15:54:13]     -- Sending DTMF 'ww2w3w1w1w1w2w5w' to the called party as result of receiving a PROGRESS message.
> ...
> [Mar  4 15:54:21]     -- Executing [s at ATA-dial:146] Dial("Local/2311125 at dtdest-00000025;2", "SIP/ATAx4,,m(1xb)G(split)") in new stack
> [Mar  4 15:54:21]   == Using SIP RTP TOS bits 184
> [Mar  4 15:54:21]   == Using SIP RTP CoS mark 5
> [Mar  4 15:54:21]     -- Called SIP/ATAx4
> [Mar  4 15:54:21]     -- Started music on hold, class '1xb', on channel 'Local/2311125 at dtdest-00000025;2'
> [Mar  4 15:54:21]     -- Local/2311125 at dtdest-00000025;1 is making progress passing it to Local/2311125 at dtroute-00000024;2
> [Mar  4 15:54:21]     -- Local/2311125 at dtroute-00000024;1 is making progress passing it to Local/TL1A1NPSTN at centrex-tielines-00000023;2
> [Mar  4 15:54:21]     -- Local/TL1A1NPSTN at centrex-tielines-00000023;1 is making progress passing it to Local/82311125 at centrex-dest-00000022;2
> [Mar  4 15:54:21]     -- Sending DTMF 'ww2w3w1w1w1w2w5w' to the called party as result of receiving a PROGRESS message.
> [Mar  4 15:54:21]     -- Local/82311125 at centrex-dest-00000022;1 is making progress passing it to SIP/ATAxLA2-0000000b
> [Mar  4 15:54:22]     -- SIP/ATAx4-0000000d is ringing
> I did a little bit more testing. This doesn't happen on calls that answer immediately, not that I expected that. The normal (on answer) usage of the D option would likely not have this bug, because a channel can only be answered once (so far as I know, unfortunately... or fortunately in this case). However, it seems that multiple progress events, even implicit ones, will cause DTMF to get sent again, as if it doesn't know it already sent the DTMF.
> On a long dial string with ws mixed in, as is often necessary since Asterisk DTMF is usually too fast for me without pauses, this means the caller often hears 10 or 15 seconds of silence before audio cuts through and just hears a dead line.
> Not sure if this is intentional, but I think either this should be kept track (DTMF already sent - not sending again) or there should be an option to just send it once.



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