[asterisk-bugs] [Asterisk 0017570]: ISDN BRI does not recover from line faults
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Aug 2 19:32:45 CDT 2010
The following issue requires your FEEDBACK.
======================================================================
https://issues.asterisk.org/view.php?id=17570
======================================================================
Reported By: jcovert
Assigned To: rmudgett
======================================================================
Project: Asterisk
Issue ID: 17570
Category: Channels/chan_dahdi
Reproducibility: random
Severity: major
Priority: normal
Status: feedback
Target Version: 1.6.2.12
Asterisk Version: 1.6.0 - SECURITY ONLY! Test 1.6.2
JIRA: SWP-1799
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-08-02 19:32 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.
======================================================================
----------------------------------------------------------------------
(0125443) rmudgett (administrator) - 2010-08-02 19:32
https://issues.asterisk.org/view.php?id=17570#c125443
----------------------------------------------------------------------
Problem seems to be because libpri Q.921 is stuck in state 2 (Assign
awaiting TEI).
Have you been seeing this error:
"Unable to receive TEI from network!"
Issue History
Date Modified Username Field Change
======================================================================
2010-08-02 19:32 rmudgett Note Added: 0125443
2010-08-02 19:32 rmudgett Status assigned => feedback
======================================================================
More information about the asterisk-bugs
mailing list