[asterisk-bugs] [Asterisk 0016710]: PRI locks randomly, hangup cause 102, "recovery on timer expiry".

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16710 
====================================================================== 
Reported By:                alecdavis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16710
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 01:07 CST
Last Modified:              2010-01-27 01:25 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.

====================================================================== 

---------------------------------------------------------------------- 
 (0117232) alecdavis (developer) - 2010-01-27 01:25
 https://issues.asterisk.org/view.php?id=16710#c117232 
---------------------------------------------------------------------- 
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 01:25 alecdavis      Note Added: 0117232                          
======================================================================