From 092134399c14b6256e1bc377951e16061dfd2331 Mon Sep 17 00:00:00 2001
From: Russell Bryant <russell@russellbryant.com>
Date: Mon, 24 Jan 2011 20:57:28 +0000
Subject: Merged revisions 303549 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r303549 | russell | 2011-01-24 14:51:37 -0600 (Mon, 24 Jan 2011) | 45 lines

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

  ................
    r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines

    Merged revisions 303546 via svnmerge from
    https://origsvn.digium.com/svn/asterisk/branches/1.4

    ........
      r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines

      Fix channel redirect out of MeetMe() and other issues with channel softhangup.

      Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
      working properly.  This issue includes a patch that resolves the issue by
      removing a call to ast_check_hangup() from app_meetme.c.  I left that in my
      patch, as it doesn't need to be there.  However, the rest of the patch fixes
      this problem with or without the change to app_meetme.

      The key difference between what happens before and after this patch is the
      effect of the END_OF_Q control frame.  After END_OF_Q is hit in ast_read(),
      ast_read() will return NULL.  With the ast_check_hangup() removed, app_meetme
      sees this which causes it to exit as intended.  Checking ast_check_hangup()
      caused app_meetme to exit earlier in the process, and the target of the
      redirect saw the condition where ast_read() returned NULL.

      Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
      solve the issue if another application did the same thing.  There are also
      other edge cases where if an application finishes at the same time that a
      redirect happens, the target of the redirect will think that the channel hung
      up.  So, I made some changes in pbx.c to resolve it at a deeper level.  There
      are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
      abort the hangup process.  My patch extends this to remove the END_OF_Q frame
      from the channel's read queue, making the "abort hangup" more complete.  This
      same technique was used in every place where a softhangup flag was cleared.

      (closes issue #18585)
      Reported by: oej
      Tested by: oej, wedhorn, russell

      Review: https://reviewboard.asterisk.org/r/1082/
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
---
 include/asterisk/channel.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

(limited to 'include/asterisk')

diff --git a/include/asterisk/channel.h b/include/asterisk/channel.h
index 78fda54b9..c9156daf1 100644
--- a/include/asterisk/channel.h
+++ b/include/asterisk/channel.h
@@ -1015,6 +1015,15 @@ enum {
 	 * instead of actually hanging up.
 	 */
 	AST_SOFTHANGUP_UNBRIDGE =  (1 << 6),
+
+
+	/*!
+	 * \brief All softhangup flags.
+	 *
+	 * This can be used as an argument to ast_channel_softhangup_clear
+	 * to clear all softhangup flags from a channel.
+	 */
+	AST_SOFTHANGUP_ALL =       (0xFFFFFFFF)
 };
 
 
@@ -1395,6 +1404,20 @@ int ast_softhangup(struct ast_channel *chan, int reason);
  */
 int ast_softhangup_nolock(struct ast_channel *chan, int reason);
 
+/*!
+ * \brief Clear a set of softhangup flags from a channel
+ *
+ * Never clear a softhangup flag from a channel directly.  Instead,
+ * use this function.  This ensures that all aspects of the softhangup
+ * process are aborted.
+ *
+ * \param chan the channel to clear the flag on
+ * \param flag the flag or flags to clear
+ *
+ * \return Nothing.
+ */
+void ast_channel_clear_softhangup(struct ast_channel *chan, int flag);
+
 /*!
  * \brief Set the source of the hangup in this channel and it's bridge
  *
-- 
cgit v1.2.3