[Home]

Summary:ASTERISK-29989: app_dial, chan_dahdi: DIALSTATUS is inconsistent for busy
Reporter:N A (InterLinked)Labels:regression
Date Opened:2022-03-27 06:04:25Date Closed:2022-06-30 18:10:01
Priority:MinorRegression?
Status:Closed/CompleteComponents:Applications/app_dial
Versions:18.6.0 Frequency of
Occurrence
Constant
Related
Issues:
is caused byASTERISK-28638 Simplify dialplan for Dial, Page, and ChanIsAvail
Environment:DebianAttachments:
Description:When an endpoint or line is BUSY, we expect a DIALSTATUS of BUSY and HANGUPCAUSE of 17.

This is how it works with PJSIP, for example:

Dialing busy PJSIP endpoint:

{noformat}
[2022-03-27 10:54:51]   == Using SIP RTP Audio TOS bits 184
[2022-03-27 10:54:51]     -- Called PJSIP/ATAxOldGrandstream1
[2022-03-27 10:54:51]     -- Local/4002702595@lines-pre-000000df;2 requested media update control 20, passing it to PJSIP/ATAxOldGrandstream1-0000002f
[2022-03-27 10:54:51]     -- Local/4002702595@lines-pre-000000df;2 requested media update control 20, passing it to PJSIP/ATAxOldGrandstream1-0000002f
[2022-03-27 10:54:51]   == Everyone is busy/congested at this time (1:1/0/0)
[2022-03-27 10:54:51]     -- Executing [4002702595@lines:3] NoOp("Local/4002702595@lines-pre-000000df;2", "BUSY / 17") in new stack
{noformat}

However, that's not what happens if you dial a busy DAHDI line:

{noformat}
[Mar 27 05:50:50]     -- Executing [2@ring:3] Dial("DAHDI/2-1", "DAHDI/2") in new stack
[Mar 27 05:50:50] DEBUG[1387][C-00000001]: app_dial.c:2299 dial_exec_full:  DAHDI/2-1: Data: DAHDI/2
[Mar 27 05:50:50] DEBUG[1387][C-00000001]: sig_analog.c:799 analog_available: analog_available 2
[Mar 27 05:50:50] WARNING[1387][C-00000001]: app_dial.c:2604 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 17 - User busy)
[Mar 27 05:50:50]     -- No devices or endpoints to dial (technology/resource)
[Mar 27 05:50:50] DEBUG[1387][C-00000001]: app_dial.c:3363 dial_exec_full: Exiting with DIALSTATUS=CHANUNAVAIL.
[Mar 27 05:50:50] DEBUG[1387][C-00000001]: app_dial.c:3394 dial_exec_full:  DAHDI/2-1: Done
[Mar 27 05:50:50] DEBUG[1387][C-00000001]: pbx.c:2938 pbx_extension_helper: Launching 'NoOp'
[Mar 27 05:50:50]     -- Executing [2@ring:4] NoOp("DAHDI/2-1", "CHANUNAVAIL / 17") in new stack
{noformat}

This is because ast_request_with_stream_topology is returning NULL, and this would succeed with other channel drivers, presumably, because Asterisk doesn't "know" if a line is busy or not until it actually tries dialing it. However, with DAHDI, it knows immediately, before we even try, so it's returning NULL here.

It's a little unclear what the appropriate fix here is. Code could be added to detect a hang up case of 17 and, if that's the case, NOT set it to CHANUNAVAIL but busy instead, right about here: https://github.com/asterisk/asterisk/blob/master/apps/app_dial.c#L2823

That would fix the problem, but not sure if that would be considered too "hacky".

Alternately, we tell everyone that using DIALSTATUS is wrong and should not be relied on, and they need to case on the HANGUPCAUSE instead... but I think the DIALSTATUS should be fixed to match the HANGUPCAUSE.

Thoughts anyone?
Comments:By: Asterisk Team (asteriskteam) 2022-03-27 06:04:26.753-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) 2022-03-27 08:17:41.207-0500

Was this caused by ASTERISK-28638 or did it always behave this way?

By: N A (InterLinked) 2022-03-27 08:51:07.584-0500

Ah... indeed, that is the exact code path it seems to be following - it gets that "No devices/endpoints" at the end and that then arbitrarily overrides the DIALSTATUS to CHANUNAVAIL.

https://gerrit.asterisk.org/c/asterisk/+/13560/1/apps/app_dial.c

Perhaps simply removing the strcpy might "fix" this issue, but I'm not sure what other implications that might have.

However, I don't think "No devices/endpoints" is the appropriate message here, either. That isn't the case - there was a device and endpoint, but it was busy - which is different than if there wasn't a device to begin with.

By: Joshua C. Colp (jcolp) 2022-03-27 10:56:21.332-0500

That's not really an answer to my question. Yes, that's the code in question - but did that change cause this, or did the behavior exist previously?

By: N A (InterLinked) 2022-03-27 11:39:51.729-0500

I hadn't tested/looked at that case, but I just downloaded the app_dial.c just before that commit.

The old app_dial.c does work correctly (I get BUSY instead of CHANUNAVAIL).

So that confirms that patch caused a regression.

By: Friendly Automation (friendly-automation) 2022-06-30 18:10:02.992-0500

Change 18673 merged by Friendly Automation:
app_dial: Fix dial status regression.

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

By: Friendly Automation (friendly-automation) 2022-07-01 10:18:50.357-0500

Change 18521 merged by Kevin Harwell:
app_dial: Fix dial status regression.

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

By: Friendly Automation (friendly-automation) 2022-07-01 10:19:15.898-0500

Change 18674 merged by Kevin Harwell:
app_dial: Fix dial status regression.

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

By: Friendly Automation (friendly-automation) 2022-07-01 10:19:40.187-0500

Change 18675 merged by Kevin Harwell:
app_dial: Fix dial status regression.

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