[Home]

Summary:ASTERISK-29329: app_dial: DTMF to 'D' option gets duplicated if there are multiple progress events
Reporter:N A (InterLinked)Labels:patch
Date Opened:2021-03-04 15:09:15.000-0600Date Closed:2021-03-10 04:23:01.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_dial
Versions:18.2.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Debian 10Attachments:( 0) 0001-app_dial.c-Only-send-DTMF-on-first-progress-event.patch
Description: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@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@ATA-dial:146] Dial("Local/2311125@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@dtdest-00000025;2'
[Mar  4 15:54:21]     -- Local/2311125@dtdest-00000025;1 is making progress passing it to Local/2311125@dtroute-00000024;2
[Mar  4 15:54:21]     -- Local/2311125@dtroute-00000024;1 is making progress passing it to Local/TL1A1NPSTN@centrex-tielines-00000023;2
[Mar  4 15:54:21]     -- Local/TL1A1NPSTN@centrex-tielines-00000023;1 is making progress passing it to Local/82311125@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@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.
Comments:By: Asterisk Team (asteriskteam) 2021-03-04 15:09:16.794-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

By: N A (InterLinked) 2021-03-06 10:59:18.000-0600

Not entirely sure what constitutes major / minor bugs, but in certain cases, it's actually more than just inconvenient. Depending on the outpulsing and inpulsing arrangement, this will result in double sending of digits onto a dial tone, resulting in mangling of the digits and making it impossible to complete certain calls. For instance, some digits might get dialed out onto a line, and then the user can finish dialing digits. Except, due to the progress bug, the digit sequence gets sent twice, and now it is impossible for the call to be completed correctly. So, I would consider this to be a "major" bug because of the major loss in function currently. Answering the channel is not an acceptable workaround because that screws with billing, and in any case that is not always under our control. Right now, we have an entire dial-9 trunk group out of commission on remote calls because of the double outpulsing.

By: Joshua C. Colp (jcolp) 2021-03-06 11:57:56.104-0600

I can move it up to Major if you'd like, but that doesn't really alter whether this will get worked or not, and when. I put it as Minor originally because I scope severity to impact to the project as a whole and the user base. The functionality you're referring to is not really used often, and even more so the progress functionality. This is the first time I even saw that it existed.

By: Sean Bright (seanbright) 2021-03-06 17:08:26.463-0600

[~InterLinked], try the [attached patch|^0001-app_dial.c-Only-send-DTMF-on-first-progress-event.patch].

By: Richard Mudgett (rmudgett) 2021-03-06 17:50:59.258-0600

This bug appears to have been in the code since the feature was first put into Asterisk in 2009 by a contributor's patch.

By: N A (InterLinked) 2021-03-06 18:45:54.553-0600

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!

By: George Joseph (gjoseph) 2021-03-08 08:39:00.917-0600

bq.  I don't see a difference between the original and the changed,

[~seanbright] Moved the "if" block that does the ast_dtmf_stream inside the "if" block that only runs if progress hasn't already been sent. :)


By: Friendly Automation (friendly-automation) 2021-03-10 04:23:02.922-0600

Change 15593 merged by Joshua Colp:
app_dial.c: Only send DTMF on first progress event.

[https://gerrit.asterisk.org/c/asterisk/+/15593|https://gerrit.asterisk.org/c/asterisk/+/15593]

By: Friendly Automation (friendly-automation) 2021-03-10 04:23:14.992-0600

Change 15576 merged by Joshua Colp:
app_dial.c: Only send DTMF on first progress event.

[https://gerrit.asterisk.org/c/asterisk/+/15576|https://gerrit.asterisk.org/c/asterisk/+/15576]

By: Friendly Automation (friendly-automation) 2021-03-10 04:23:27.811-0600

Change 15575 merged by Joshua Colp:
app_dial.c: Only send DTMF on first progress event.

[https://gerrit.asterisk.org/c/asterisk/+/15575|https://gerrit.asterisk.org/c/asterisk/+/15575]