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 #15671)
Reported by: jcromes
Patches:
      issue15671.patch uploaded by pabelanger (license 224)
Tested by: jcromes

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@313188 65c4cc65-6c06-0410-ace0-fbb531ad65f3

diff --git a/channels/chan_dahdi.c b/channels/chan_dahdi.c
index 24083ea88286c909c17c86a4cf9a50b089951f37..449ccaf47c30e557639e0d210af8ca7b5d048ef7 100644 (file)
--- a/channels/chan_dahdi.c
+++ b/channels/chan_dahdi.c
@@ -6668,7 +6668,10 @@ static void *ss_thread(void *data)
                         /* some switches require a minimum guard time between
                            the last FGD wink and something that answers
                            immediately. This ensures it */
-                        if (ast_safe_sleep(chan,100)) goto quit;
+                       if (ast_safe_sleep(chan, 100)) {
+                               ast_hangup(chan);
+                               goto quit;
+                       }
                }
                dahdi_enable_ec(p);
                if (NEED_MFDETECT(p)) {