[asterisk-bugs] [Asterisk 0016713]: PRI locks randomly, hangup cause 102, "recovery on timer expiry".
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Jan 27 04:23:36 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16713
======================================================================
Reported By: alecdavis
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16713
Category: Channels/chan_dahdi
Reproducibility: random
Severity: block
Priority: normal
Status: new
Asterisk Version: SVN
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1
SVN Revision (number only!): 241456
Request Review:
======================================================================
Date Submitted: 2010-01-27 04:21 CST
Last Modified: 2010-01-27 04:23 CST
======================================================================
Summary: PRI locks randomly, hangup cause 102, "recovery on
timer expiry".
Description:
Every week once or twice our PRI locks up. The easiest way I've found to
get it started again is to issue at the CLI 'dahdi restart'
When it is locked up, inbound pri calls are not accepted.
======================================================================
----------------------------------------------------------------------
(0117235) alecdavis (developer) - 2010-01-27 04:23
https://issues.asterisk.org/view.php?id=16713#c117235
----------------------------------------------------------------------
libpri version: SVN-branch-1.4-r1374M
DAHDI Version: SVN-branch-2.2-r7684 Echo Canceller: MG2
Asterisk SVN-branch-1.6.1-r241456M
uploaded pri_locked.txt
This is one of our staff trying to call into our IVR.
Just after that call I issued 'dahdi restart' from CLI, and all calls
start flowing again.
It seems like, if a CAUSE 102 is received on the ISDN, we should soft
restart the channel it was received on, or something to that effect. As I
understand it, existing calls would still be working, but in this capture,
none were going.
Issue History
Date Modified Username Field Change
======================================================================
2010-01-27 04:23 alecdavis Note Added: 0117235
======================================================================
More information about the asterisk-bugs
mailing list