app: Queue hangup if channel is hung up during sub or macro execution.

This issue was exposed when executing a connected line subroutine.
When connected or redirected subroutines or macros are executed it is
expected that the underlying applications and logic invoked are fast
and do not consume frames. In practice this constraint is not enforced
and if not adhered to will cause channels to continue when they shouldn't.
This is because each caller of the connected or redirected logic does not
check whether the channel has been hung up on return. As a result the
the hung up channel continues.

This change makes it so when the API to execute a subroutine or
macro is invoked the channel is checked to determine if it has hung up.
If it has then a hangup is queued again so the caller will see it
and stop.

ASTERISK-25690 #close

Change-Id: I1f9a8ceb1487df0389f0d346ce0f6dcbcaf476ea

1 files changed, 10 insertions, 0 deletions

diff --git a/main/app.c b/main/app.c
index c4143d840..a89e5b06f 100644
--- a/main/app.c
+++ b/main/app.c
@@ -357,6 +357,11 @@ int ast_app_exec_macro(struct ast_channel *autoservice_chan, struct ast_channel
 	if (autoservice_chan) {
 		ast_autoservice_stop(autoservice_chan);
 	}
+
+	if (ast_check_hangup_locked(macro_chan)) {
+		ast_queue_hangup(macro_chan);
+	}
+
 	return res;
 }
 
@@ -433,6 +438,11 @@ int ast_app_exec_sub(struct ast_channel *autoservice_chan, struct ast_channel *s
 	if (autoservice_chan) {
 		ast_autoservice_stop(autoservice_chan);
 	}
+
+	if (!ignore_hangup && ast_check_hangup_locked(sub_chan)) {
+		ast_queue_hangup(sub_chan);
+	}
+
 	return res;
 }