[asterisk-bugs] [Asterisk 0014030]: mISDN layer stops working

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14030 
====================================================================== 
Reported By:                t-o
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   14030
Category:                   Channels/chan_misdn
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-12-08 07:11 CST
Last Modified:              2009-04-13 12:29 CDT
====================================================================== 
Summary:                    mISDN layer stops working
Description: 
After having accepted a lot of calls, the mISDN layer gets unusable; no
more calls are accepted.

asterix*CLI> misdn show channels
Chan List: 0x83872c0
bc with pid:0 has no Ast Leg
P[ 0] received 1k Unhandled Bchannel Messages: prim 120282 len 128
from addr 52010101, dinfo ffffffff on this port.

A restart of the asterisk software clears the problem.
====================================================================== 

---------------------------------------------------------------------- 
 (0103162) rmudgett (administrator) - 2009-04-13 12:29
 http://bugs.digium.com/view.php?id=14030#c103162 
---------------------------------------------------------------------- 
The attached single line patch file (mISDN_deadlock.patch) applies to mISDN
1.1.8, 1.1.9.x, and should work for other 1.1.x versions of mISDN.  Please
report if this resolves the issue.


Added handling of EV_RELEASE_CNF to ST_L3_LC_ESTAB_WAIT state to bring L2
back up.

The mISDN L2 and L3 state machines could get into a deadlocked condition
while L2 is going down just as the TE side attempts to initiate a call
or respond to an incoming call.

JIRA ABE-1816, issue 14030

Sequence of events between L2 and L3:
ST_L3_LC_ESTAB::EV_RELEASE_REQ -> ST_L3_LC_REL_DELAY
        Event for various reasons when L3 is no longer needed.
        i.e. RELEASE_COMPLETE is sent.
ST_L3_LC_REL_DELAY::TIMEOUT -> ST_L3_LC_REL_WAIT
        Event sent to L2 state machine to initiate bringing L2 down.
ST_L2_7::EV_L2_DL_RELEASE_REQ -> ST_L2_6
        L2 sends disconnect and waits for a reply.
ST_L3_LC_REL_WAIT::EV_ESTABLISH_REQ -> ST_L3_LC_ESTAB_WAIT
        L3 message (SETUP, SETUP_ACK, or PROCEEDING) attempts to bring
        L2 back up by sending event to L2 to establish link.
ST_L2_6::EV_L2_DL_ESTABLISH_REQ (Ignored)
        L2 is busy still waiting for a reply to the disconnect.
ST_L2_6::EV_L2_UA -> ST_L2_4
        L2 completes going down and sends event to L3.
ST_L3_LC_ESTAB_WAIT::EV_RELEASE_CNF (Ignored)
        L3 thinks L2 is trying to go up so does not know what
        to do when L2 confirms that is has completed going down.
ST_L3_LC_ESTAB_WAIT::EV_ESTABLISH_REQ (Ignored)
        Subsequent messages cannot go out because L3 is already
        waiting for L2 to go up.  Since L2 is never going
        to try to go up anymore, the state machines are
        deadlocked. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-13 12:29 rmudgett       Note Added: 0103162                          
======================================================================