[asterisk-bugs] [JIRA] (ASTERISK-28615) chan_dahdi: PRI span status may stay "Down, Active" after a short alarm

[Frederic LE FOLL (JIRA)]

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

Frederic LE FOLL commented on ASTERISK-28615:
---------------------------------------------

Analysis:

This problem occurs because chan_dahdi (through sig_pri) has 2 status bits:
- DCHAN_NOTINALARM
- DCHAN_UP
sig_pri updates these bits depending on alarms and events that come from libpri:
- it clears both bits when it receives an Alarm,
- it also clears DCHAN_UP when it receives PRI_EVENT_DCHAN_DOWN event,
- it sets DCHAN_UP when it receives any event except PRI_EVENT_DCHAN_DOWN (including PRI_EVENT_DCHAN_UP, but also PRI_EVENT_RING that notifies a new call).

Due to Q.921 timers and repetitions, as implemented in libpri, libpri may not break layer 2 for every link disconnection, depending on
disconnection duration and remote end behavior.
This can be observed with "pri set debug intense".

Especially, with two Asterisk face-to-face, layer 2 will remain up for a short disconnection (duration compared to T200 x N200).
As a consequence:
1) disconnection: libpri will notify an Alarm (but no PRI_EVENT_DCHAN_DOWN) => sig_pri clears DCHAN_UP.
2) reconnection: libpri will notify an End Of Alarm (but no PRI_EVENT_DCHAN_UP) => DCHAN_UP remains cleared.
Later:
3) Activity in D-Channel (SETUP for an incoming call) => sig_pri sets DCHAN_UP.

According to status bits naming, DCHAN_NOTINALARM should represent the presence of an alarm, while DCHAN_UP should represent only
D-Channel status.
So, it would seem better if alarms only impact DCHAN_NOTINALARM bit, while PRI_EVENT_DCHAN_DOWN, PRI_EVENT_DCHAN_UP (or any event PRI_EVENT_... showing that D-Channel indeed is 'up') should impact DCHAN_UP.

Due to current alarm processing in sig_pri, chan_dahdi/sig_pri and libpri thus have a different vision of D-Channel status, after a short alarm that does not break Q.921 layer:
- D-Channel is still 'up' for libpri,
- D-Channel is 'down' for chan_dahdi/sig_pri.

This it not new: sig_pri has implemented this DCHAN_UP processing since Asterisk 1.0.0.
Maybe it was necessary with former versions of libpri, but it does not seem as pertinent with current libpri (libpri 1.6.0 will send a PRI_EVENT_DCHAN_DOWN if disconnection persists, or if remote end resets link upon reconnection).

Changing sig_pri pri_event_alarm() function, in order to modify DCHAN_NOTINALARM only, affects following functions:
- sig_pri_ami_show_spans(),
- sig_pri_cli_show_spans()/sig_pri_cli_show_span() through build_status().
Through DCHAN_AVAILABLE, it also affects pri_is_up() and pri_find_dchan(), thus restarts and idle channels processing in
pri_dchannel() [at first sight when reading pri_dchannel()]. Here also, the change should allow sig_pri to handle spans according to their real D-Channel status, as determined by libpri.

I would like to propose a change throught Gerrit, in association with this issue.

> chan_dahdi: PRI span status may stay "Down, Active" after a short alarm
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-28615
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28615
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: 16.4.0
>         Environment: Asterisk with Digium PRI card
>            Reporter: Frederic LE FOLL
>            Severity: Minor
>
> Nominal status for an ISDN PRI is "Up, Active" (CLI pri show spans).
> Upon a disconnection, span status becomes "In Alarm, Down, Active".
> If disconnection is short enough, span status becomes, and remains,
> "Down, Active".
> Later, status goes back "Up, Active" if an incoming call is presented.
> The problem seems to occur or not, depending on remote end.
> It happens with two Asterisk face-to-face.



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