[asterisk-bugs] [Asterisk 0015671]: [patch] Stuck channel using FEATD_MF if caller hangs up at the right time

Asterisk Bug Tracker noreply at bugs.digium.com
Mon Apr 11 10:40:31 CDT 2011


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15671 
====================================================================== 
Reported By:                jcromes
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   15671
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                       SWP-1813 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-08-06 21:29 CDT
Last Modified:              2011-04-11 10:40 CDT
====================================================================== 
Summary:                    [patch] Stuck channel using FEATD_MF if caller hangs
up at the right time
Description: 
CentOS 5.2 x86_64
Asterisk 1.4.26
Zaptel 1.4.12.1
Digium TE412P 

This box's purpose is to be a conferencing server, so it takes almost
entirely inbound calls.  All 4 spans of my TE412P are configured as
FEATD_MF, and are connected to a Nortel DMS-100 switch.  (I can't do PRI.) 
The system has worked great for quite a long time, except every once in a
while, a channel would get stuck in "Ring" state. For example:

>> show channels
Channel       Location        State    Application(Data)     
Zap/77-1      s at tdma:1        Ring     (None)               
1 active channel
0 active calls 

The DMS-100 would show this channel "idle" while it was stuck in Asterisk.
It would remain stuck like this permanently until I restarted Asterisk.
Once I did that (and nothing else), the channel would clear again with no
problems. 

-----

The cause, I discovered, was actually a caller hanging up just at the end
of the Feature Group D DTMF tones that setup the call.  The reason for this
is a "guard timer" that's implemented using ast_safe_sleep(100) on line
6189 of chan_dahdi.c.  If the caller happens to hang up AFTER the final
tone of the DTMF string but BEFORE the end of that ast_safe_sleep(), then
ast_safe_sleep() will return non-zero.  This causes the code to bounce to
the end of ss_thread, but it does NOT tear down the call properly.

This should be a rare occurrence because the caller has to hang up at
EXACTLY the right time.  Nonetheless, it was happening quite regularly on
my system.  It's not easily reproducible, unless you purposely increase the
guard-time to 2000 or more.  Once do that, you can reproduce it every time
by watching the DTMF debug and hanging up just as it ends.

The solution was to change line 6189 from this:
if (ast_safe_sleep(chan,100)) goto quit;

...to this:
if (ast_safe_sleep(chan,100)) { ast_hangup(chan);  goto quit; }

I'm not very familiar with Asterisk channel handling conventions, so there
may be a better way fix this problem.  I did, however, put some extra
logging code in my local system and I have evidence of the situation
occurring and exiting cleanly.  I have 6 weeks of runtime with 0 stuck
channels at the moment.

Thanks.
====================================================================== 

---------------------------------------------------------------------- 
 (0133594) svnbot (reporter) - 2011-04-11 10:40
 https://issues.asterisk.org/view.php?id=15671#c133594 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 313190

_U  branches/1.8/
U   branches/1.8/channels/chan_dahdi.c
U   branches/1.8/channels/sig_analog.c

------------------------------------------------------------------------
r313190 | rmudgett | 2011-04-11 10:40:31 -0500 (Mon, 11 Apr 2011) | 39
lines

Merged revisions 313189 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r313189 | rmudgett | 2011-04-11 10:32:53 -0500 (Mon, 11 Apr 2011) | 32
lines
  
  Merged revisions 313188 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r313188 | rmudgett | 2011-04-11 10:27:52 -0500 (Mon, 11 Apr 2011) | 25
lines
    
    Stuck channel using FEATD_MF if caller hangs up at the right time.
    
    The cause was actually a caller hanging up just at the end of the
Feature
    Group D DTMF tones that setup the call.  The reason for this is a
"guard
    timer" that's implemented using ast_safe_sleep(100).  If the caller
    happens to hang up AFTER the final tone of the DTMF string but BEFORE
the
    end of that ast_safe_sleep(), then ast_safe_sleep() will return
non-zero.
    This causes the code to bounce to the end of ss_thread(), but it does
NOT
    tear down the call properly.
    
    This should be a rare occurrence because the caller has to hang up at
    EXACTLY the right time.  Nonetheless, it was happening quite regularly
on
    the reporter's system.  It's not easily reproducible, unless you
purposely
    increase the guard-time to 2000 or more.  Once you do that, you can
    reproduce it every time by watching the DTMF debug and hanging up just
as
    it ends.
    
    Simply add an ast_hangup() before goto quit.
    
    (closes issue https://issues.asterisk.org/view.php?id=15671)
    Reported by: jcromes
    Patches:
          issue15671.patch uploaded by pabelanger (license 224)
    Tested by: jcromes
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=313190 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-11 10:40 svnbot         Checkin                                      
2011-04-11 10:40 svnbot         Note Added: 0133594                          
======================================================================




More information about the asterisk-bugs mailing list