From 987fdfb444aef3eb60041887db60b54e4e382293 Mon Sep 17 00:00:00 2001 From: "David M. Lee" Date: Tue, 13 Aug 2013 15:27:32 +0000 Subject: ARI: allow other operations to happen while bridged This patch changes ARI bridging to allow other channel operations to happen while the channel is bridged. ARI channel operations are designed to queue up and execute sequentially. This meant, though, that while a channel was bridged, any other channel operations would queue up and execute only after the channel left the bridge. This patch changes ARI bridging so that channel commands can execute while the channel is bridged. For most operations, things simply work as expected. The one thing that ended up being a bit odd is recording. The current recording implementation will fail when one attempts to record a channel that's in a bridge. Note that the bridge itself may be recording; it's recording a specific channel in the bridge that fails. While this is an annoying limitation, channel recording is still very useful for use cases such as voice mail, and bridge recording makes up much of the difference for other use cases. (closes issue ASTERISK-22084) Review: https://reviewboard.asterisk.org/r/2726/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396568 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- res/res_stasis.c | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'res/res_stasis.c') diff --git a/res/res_stasis.c b/res/res_stasis.c index e4ad97eae..b64f40ca9 100644 --- a/res/res_stasis.c +++ b/res/res_stasis.c @@ -594,6 +594,13 @@ int stasis_app_exec(struct ast_channel *chan, const char *app_name, int argc, int r; int command_count; + if (stasis_app_get_bridge(control)) { + /* Bridge is handling channel frames */ + control_wait(control); + control_dispatch_all(control, chan); + continue; + } + r = ast_waitfor(chan, MAX_WAIT_MS); if (r < 0) { -- cgit v1.2.3