[asterisk-bugs] [JIRA] (ASTERISK-30274) chan_dahdi: Unavailable channels are BUSY

N A (JIRA) noreply at issues.asterisk.org
Sun Oct 23 15:39:08 CDT 2022


     [ https://issues.asterisk.org/jira/browse/ASTERISK-30274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

N A updated ASTERISK-30274:
---------------------------

    Description: 
ASTERISK-29989 fixed an issue a while back where busy channels were unavailable when they weren't.

Well, we now have the reverse issue: unavailable channels are busy when they're not.

(e.g. mixup of BUSY and CHANUNAVAIL)

Ultimately, the underlying issue here seems to be that the current mechanism of determining whether a DAHDI channel is insufficient. If the peer is available but in use, it should be busy, and if it's not available at all then it should be CHANUNAVAIL.

This is actually not a regression, the problem is in chan_dahdi and not app_dial.

I don't have a solution just yet but you can assign this to me.

  was:
ASTERISK-29989 fixed an issue a while back where busy channels were unavailable when they weren't.

Well, we now have the reverse issue: unavailable channels are busy when they're not.

(e.g. mixup of BUSY and CHANUNAVAIL)

Ultimately, the underlying issue here seems to be that the current mechanism of determining whether a DAHDI channel is insufficient. If the peer is available but in use, it should be busy, and if it's not available at all then it should be CHANUNAVAIL.

I don't have a solution yet but you can assign it to me for now anyways.


> chan_dahdi: Unavailable channels are BUSY
> -----------------------------------------
>
>                 Key: ASTERISK-30274
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30274
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: 18.15.0
>            Reporter: N A
>            Severity: Major
>
> ASTERISK-29989 fixed an issue a while back where busy channels were unavailable when they weren't.
> Well, we now have the reverse issue: unavailable channels are busy when they're not.
> (e.g. mixup of BUSY and CHANUNAVAIL)
> Ultimately, the underlying issue here seems to be that the current mechanism of determining whether a DAHDI channel is insufficient. If the peer is available but in use, it should be busy, and if it's not available at all then it should be CHANUNAVAIL.
> This is actually not a regression, the problem is in chan_dahdi and not app_dial.
> I don't have a solution just yet but you can assign this to me.



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



More information about the asterisk-bugs mailing list