Summary:	ASTERISK-29516: app_senddtmf / local: Sending DTMF does not work when not answered
Reporter:	N A (InterLinked)	Labels:
Date Opened:	2021-07-09 07:25:14	Date Closed:	2023-03-16 10:41:03
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Applications/app_senddtmf Channels/chan_local
Versions:	18.5.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	For some reason, SendDTMF() does not work unless preceded by an Answer(). It does not work with Progress(), bizarrely enough. If the channel is not answered, the application will run for the right amount of time, but no audio is actually audible on the channel, even though all looks well from the CLI. This currently makes the application unsuitable for a number of applications. This occurs even when the parent channel is answered: {noformat} [ctest1] exten => s,1,Set(CDR_PROP(disable)=1) same => n,Progress() same => n,SendDTMF(${CALLERID(num)}) same => n,Hangup() [orig-line] exten => _[A-D0-9*#s]!,1,Set(CDR_PROP(disable)=1) same => n,Answer() same => n,Dial(Local/s@ctest1/n) same => n,Wait(60) [2021-07-09 12:39:57]     -- Executing [1@orig-line-pjsip:1] Goto("PJSIP/ATAxLA1-00000170", "orig-line,1,1") in new stack [2021-07-09 12:39:57]     -- Goto (orig-line,1,1) [2021-07-09 12:39:57]     -- Executing [1@orig-line:1] Set("PJSIP/ATAxLA1-00000170", "CDR_PROP(disable)=1") in new stack [2021-07-09 12:39:57]     -- Executing [1@orig-line:2] Answer("PJSIP/ATAxLA1-00000170", "") in new stack [2021-07-09 12:39:57]     -- Executing [1@orig-line:3] Dial("PJSIP/ATAxLA1-00000170", "Local/s@ctest1/n") in new stack [2021-07-09 12:39:57]     -- Called Local/s@ctest1/n [2021-07-09 12:39:57]     -- Executing [s@ctest1:1] Set("Local/s@ctest1-0000046b;2", "CDR_PROP(disable)=1") in new stack [2021-07-09 12:39:57]     -- Executing [s@ctest1:2] Progress("Local/s@ctest1-0000046b;2", "") in new stack [2021-07-09 12:39:57]     -- Local/s@ctest1-0000046b;1 is making progress passing it to PJSIP/ATAxLA1-00000170 [2021-07-09 12:39:57]     -- Executing [s@ctest1:3] SendDTMF("Local/s@ctest1-0000046b;2", "4002702126") in new stack [2021-07-09 12:40:01]     -- Executing [s@ctest1:4] Hangup("Local/s@ctest1-0000046b;2", "") in new stack [2021-07-09 12:40:01]   == Spawn extension (ctest1, s, 4) exited non-zero on 'Local/s@ctest1-0000046b;2' [2021-07-09 12:40:01]     -- No one is available to answer at this time (1:0/0/0) [2021-07-09 12:40:01]     -- Executing [1@orig-line:4] Wait("PJSIP/ATAxLA1-00000170", "60") in new stack {noformat} In this minimally reproducible example, no audio whatsoever is audible. If the Progress in ctest1 is changed to Answer, the DTMF is audible as expected.
Comments:	By: Asterisk Team (asteriskteam) 2021-07-09 07:25:16.700-0500 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: Joshua C. Colp (jcolp) 2021-07-09 07:34:08.797-0500 The app_senddtmf module doesn't know or care about answered or progress. It also doesn't produce DTMF as audio directly for most channel drivers. It tells the underlying channel to send the DTMF, and it is then up to the channel driver to do that. Any requirement of answer/progress/etc is a channel specific requirement and in some cases an upstream requirement. To that end you'll need to provide an actual console log, SIP trace if using SIP, configuration. By: N A (InterLinked) 2021-07-09 07:42:19.413-0500 The actual channel driver is PJSIP in this case, but the PJSIP channel is answered, so I assume this would not be an issue with PJSIP, possibly an issue with the Local channel driver, if a channel driver issue? By: Joshua C. Colp (jcolp) 2021-07-09 07:48:05.618-0500 Entirely possible, or because you've now included Dial() usage and a Local channel it could also be that app_dial is not forwarding the DTMF back since the common use case would be the dialing channel providing DTMF, not the dialed channel. By: N A (InterLinked) 2021-07-09 07:59:13.922-0500 It happens even with more complicated setups like a local channel Originated into a ConfBridge - this is just a simple, reproducible example. Given this, it seems like it would be something more basic in the core which would cause it to not work in both scenarios. I tried to use FRAME_TRACE to debug whether there were any actual DTMF frames on the channel, but that seems to work only with frames in the RX direction, not the TX direction. By: Joshua C. Colp (jcolp) 2021-07-09 08:05:19.281-0500 What are the scenarios you are aware of where this occurs so if this issue is worked, it can be confirmed resolved in each places and so that it provides better scope on where the issue could be? By: N A (InterLinked) 2021-07-09 08:16:02.310-0500 Essentially the two I just mentioned. This issue does *not* occur directly on the PJSIP channel driver. If a call comes into Asterisk, Progress, SendDTMF, Answer, SendDTMF - they both work. So this issue is not PJSIP related. I looked in app_dial and I don't see anything in that file at least that would be inhibiting DTMF from going back in the other direction. I always answer channels on the actual channel driver as soon as they come into Asterisk, first thing, and do actual call processing in the dialplan, so these are with that in mind (that PJSIP itself is "up"): - Dialing a Local channel that doesn't answer but does Progress. No audio audible. If Answered, audible. - Originating a Local channel into a ConfBridge and then having both the PJSIP and originated channel join the bridge. The local channel DTMF isn't audible with Progress, but is with Answer. If SendDTMF is indeed happily sending DTMF as the case seems to be, then somehow it seems to be getting "eaten up" in the unanswered Local channel. Obviously regular in band audio is audible, so if I created a bunch of DTMF audio files and played those with Playback(,noanswer), that would work around the issue by sending it in band instead of as DTMF frames. I can't really think of further bridging scenarios that are radically different, but it seems potentially Local related, same underlying issue for both cases, and I could confirm the issue is resolved if a patch were available. By: N A (InterLinked) 2022-02-26 07:13:09.527-0600 I can confirm this issue occurs with SIP as well as PJSIP - likely a core RTP or related issue of some kind. By: Friendly Automation (friendly-automation) 2023-03-16 10:41:04.429-0500 Change 19937 merged by Joshua Colp: app_dial: Fix DTMF not relayed to caller on unanswered calls. [https://gerrit.asterisk.org/c/asterisk/+/19937|https://gerrit.asterisk.org/c/asterisk/+/19937] By: Friendly Automation (friendly-automation) 2023-03-16 10:41:18.674-0500 Change 19981 merged by Joshua Colp: app_dial: Fix DTMF not relayed to caller on unanswered calls. [https://gerrit.asterisk.org/c/asterisk/+/19981|https://gerrit.asterisk.org/c/asterisk/+/19981] By: Friendly Automation (friendly-automation) 2023-03-16 10:41:36.514-0500 Change 19980 merged by Joshua Colp: app_dial: Fix DTMF not relayed to caller on unanswered calls. [https://gerrit.asterisk.org/c/asterisk/+/19980|https://gerrit.asterisk.org/c/asterisk/+/19980]