]> git.ipfire.org Git - thirdparty/asterisk.git/commitdiff
stasis: Call callbacks when imparting fails
authorHolger Hans Peter Freyther <holger@moiji-mobile.com>
Wed, 10 Apr 2019 04:30:25 +0000 (05:30 +0100)
committerJoshua Colp <jcolp@digium.com>
Thu, 2 May 2019 15:28:21 +0000 (15:28 +0000)
After a bridge has been deleted the stasis control will depart
the channel and might attempt to re-add it to the dial bridge.

The later can fail and this can lead to a situation that the stasis
control is unlinked but the after_bridge_cb_failed cb is executed trying
to access a dangling control object.

Fix it by calling the after_cb's before bridge_channel_impart_signal.

ASTERISK-26718

Change-Id: Ib4e8f70d7a21bd54afe3cb51cc6717ef7c355496

include/asterisk/bridge.h
main/bridge.c

index dc8ebe5ec488f1491a2d82e3ced6465c0c4535af..13fa19190d598641a642c075f9373437103ed8b7 100644 (file)
@@ -594,6 +594,9 @@ enum ast_bridge_impart_flags {
  * it were placed into the bridge by ast_bridge_join().
  * Channels placed into a bridge by ast_bridge_join() are
  * removed by a third party using ast_bridge_remove().
+ *
+ * \note Any callbacks on the channel will be invoked on failure
+ * with the reason as AST_BRIDGE_AFTER_CB_REASON_IMPART_FAILED.
  */
 int ast_bridge_impart(struct ast_bridge *bridge,
        struct ast_channel *chan,
index f3c34d1fe3756262827bad642678ca9d5c486e32..9c53cfb5acc82441c7a0232f28f1b6efe8960108 100644 (file)
@@ -1953,6 +1953,7 @@ int ast_bridge_impart(struct ast_bridge *bridge,
        res = bridge_impart_internal(bridge, chan, swap, features, flags, &cond);
        if (res) {
                /* Impart failed.  Signal any other waiting impart threads */
+               ast_bridge_discard_after_callback(chan, AST_BRIDGE_AFTER_CB_REASON_IMPART_FAILED);
                bridge_channel_impart_signal(chan);
        }