[asterisk-bugs] [Asterisk 0017570]: ISDN BRI does not recover from line faults
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Jun 30 13:47:44 CDT 2010
The following issue requires your FEEDBACK.
======================================================================
https://issues.asterisk.org/view.php?id=17570
======================================================================
Reported By: jcovert
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 17570
Category: Channels/chan_dahdi
Reproducibility: random
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.6.0 - SECURITY ONLY! Test 1.6.2
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-06-30 08:30 CDT
Last Modified: 2010-06-30 13:47 CDT
======================================================================
Summary: ISDN BRI does not recover from line faults
Description:
DAHDI Version: 2.3.0.1 Echo Canceller: MG2
Libpri version: libpri-1.4.11.1
About once every 3-4 weeks, some sort of error occurs on one or more of
three Sovitel ISDN BRI circuits. Afterwards, all calls fail, and there is
no logging information available on call attempts:
The following appeared in the messages log about the time of the failure:
[Jun 30 12:13:16] WARNING[3241] chan_dahdi.c: Detected alarm on channel 5:
Red Alarm
[Jun 30 12:13:16] NOTICE[3239] chan_dahdi.c: PRI got event: Alarm (4) on
Primary D-channel of span 2
[Jun 30 12:13:16] WARNING[3239] chan_dahdi.c: No D-channels available!
Using Primary channel 6 as D-channel anyway!
[Jun 30 12:13:16] WARNING[2131] chan_dahdi.c: Detected alarm on channel 4:
Red Alarm
[Jun 30 12:13:44] NOTICE[2131] chan_dahdi.c: Alarm cleared on channel 4
[Jun 30 12:13:44] NOTICE[3241] chan_dahdi.c: Alarm cleared on channel 5
[Jun 30 12:13:44] NOTICE[3239] chan_dahdi.c: PRI got event: No more alarm
(5) on Primary D-channel of span 2
Further outgoing call attempts reported:
Moscow-Asterisk*CLI> pri intensive debug span 2
Enabled EXTENSIVE debugging on span 2
-- Accepting AUTHENTICATED call from 205.153.37.207:
> requested format = gsm,
> requested prefs = (gsm|ulaw|alaw),
> actual format = ulaw,
> host prefs = (ulaw|alaw),
> priority = mine
-- Executing [800954100 at from-dc:1] Dial("IAX2/npr-dc-pbx-11375",
"DAHDI/4/100,120") in new stack
[Jun 30 16:21:08] WARNING[3894]: app_dial.c:1502 dial_exec_full: Unable to
create channel of type 'DAHDI' (cause 0 - Unknown)
== Everyone is busy/congested at this time (1:0/0/1)
While in failure, we have seen the following messages:
TEI: 125 State 2CLI>
V(S) 0 V(A) 0 V(R) 0
K 1, RC 0, l3initiated 0, reject_except 0 ack_pend 0
T200 0, N200 3, T203 0
< [ fe ff 03 0f 00 00 04 ff ]
< Unnumbered frame:
< SAPI: 63 C/R: 1 EA: 0
< TEI: 127 EA: 1
< M3: 0 P/F: 0 M2: 0 11: 3 [ UI (unnumbered information) ]
< 5 bytes of data
< MDL Message: TEI Identity Check Request (4)
< RI: 0
< Ai: 127 E:1
Received MDL message
== Spawn extension (from-dc, 109, 5) exited non-zero on
'IAX2/npr-dc-pbx-10603'
-- Executing [h at from-dc:1] ExecIf("IAX2/npr-dc-pbx-10603", "0?System(
\; )") in new stack
-- Hungup 'IAX2/npr-dc-pbx-10603'
TEI: 125 State 2
V(S) 0 V(A) 0 V(R) 0
K 1, RC 0, l3initiated 0, reject_except 0 ack_pend 0
T200 0, N200 3, T203 0
< [ fe ff 03 0f 00 00 04 ff ]
< Unnumbered frame:
< SAPI: 63 C/R: 1 EA: 0
< TEI: 127 EA: 1
< M3: 0 P/F: 0 M2: 0 11: 3 [ UI (unnumbered information) ]
< 5 bytes of data
< MDL Message: TEI Identity Check Request (4)
< RI: 0
< Ai: 127 E:1
Received MDL message
We have provided the office staff a special dial code which restarts DAHDI
and emails us:
-- Executing [109 at privileged-station:3]
System("Local/109 at privileged-station-8477;2", "asterisk -rx 'dahdi
restart'") in new stack
-- Remote UNIX connection
Destroying channels and reloading DAHDI configuration.
-- User hung up>
== Spawn extension (macro-astextn, s, 7) exited non-zero on 'DAHDI/4-1'
in macro 'astextn'
== Spawn extension (macro-astextn, s, 7) exited non-zero on 'DAHDI/4-1'
-- Executing [h at macro-astextn:1] ExecIf("DAHDI/4-1",
"1?System(/usr/local/bin/sipsak -H 172.19.19.240 -i -M -B '' -s
sip:x3293 at 172.19.19.105:1024 \; )") in new stack
-- Hungup 'DAHDI/4-1'
== Unregistered channel -2
== Unregistered channel 1
== Unregistered channel 2
== Unregistered channel 4
== Unregistered channel 5
== Unregistered channel 7
== Unregistered channel 8
== Parsing '/etc/asterisk/chan_dahdi.conf': == Found
== Parsing '/etc/asterisk/users.conf': == Found
-- Reconfigured channel 1, ISDN BRI Point to MultiPoint signalling
-- Reconfigured channel 2, ISDN BRI Point to MultiPoint signalling
-- Reconfigured channel 4, ISDN BRI Point to MultiPoint signalling
-- Reconfigured channel 5, ISDN BRI Point to MultiPoint signalling
-- Reconfigured channel 7, ISDN BRI Point to MultiPoint signalling
-- Reconfigured channel 8, ISDN BRI Point to MultiPoint signalling
== Starting D-Channel on span 1
== Starting D-Channel on span 2
== Starting D-Channel on span 3
== Primary D-Channel on span 2 up
== Primary D-Channel on span 3 up
== Primary D-Channel on span 1 up
If there is any further information we could collect prior to the restart
that would help debug, please let us know.
======================================================================
----------------------------------------------------------------------
(0124111) lmadsen (administrator) - 2010-06-30 13:47
https://issues.asterisk.org/view.php?id=17570#c124111
----------------------------------------------------------------------
I'm not sure if there is anything additional we can do here as (even though
https://issues.asterisk.org/view.php?id=17521 is blocking you) the 1.6.0 branch
is no longer supported beyond
security issues.
However, additional logging may be useful to help track down the issue,
but can't guarantee how high on the priority list this is going to make it
without verifying and reproducing the issue on the 1.6.2 branch.
Can you show the output of 'core show locks' when this happens? A
backtrace of the running process when this happens may also be useful.
Issue History
Date Modified Username Field Change
======================================================================
2010-06-30 13:47 lmadsen Note Added: 0124111
2010-06-30 13:47 lmadsen Status new => feedback
======================================================================
More information about the asterisk-bugs
mailing list