[asterisk-bugs] [JIRA] (ASTERISK-29989) app_dial, chan_dahdi: DIALSTATUS is inconsistent for busy

[N A (JIRA)]

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

N A commented on ASTERISK-29989:
--------------------------------

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.

> app_dial, chan_dahdi: DIALSTATUS is inconsistent for busy
> ---------------------------------------------------------
>
>                 Key: ASTERISK-29989
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29989
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_dial
>    Affects Versions: 18.6.0
>         Environment: Debian
>            Reporter: N A
>            Assignee: Unassigned
>
> 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 at lines-pre-000000df;2 requested media update control 20, passing it to PJSIP/ATAxOldGrandstream1-0000002f
> [2022-03-27 10:54:51]     -- Local/4002702595 at 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 at lines:3] NoOp("Local/4002702595 at 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 at 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 at 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?



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