]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_stasis: Fix stale data in ARI bridges
authorMoritz Fain <moritz@fain.io>
Tue, 26 Jun 2018 14:17:37 +0000 (16:17 +0200)
committerRichard Mudgett <rmudgett@digium.com>
Wed, 26 Sep 2018 23:50:09 +0000 (18:50 -0500)
commit27c46b8ff36fc14ef2831924e8704477b745db19
tree16499d8c16959ce78e4c559957efd9095c818400
parent4ddca5316417c7a84f563159fe7e3ea2fe891c6b
res_stasis: Fix stale data in ARI bridges

Fixed an issue that resulted in "Allocation failed" each time an ARI
request was made to start playing MOH on a bridge.

In bridge_moh_create() we were attaching the after bridge callbacks to
chan which is the ;1 channel of the unreal channel pair.  We should have
attached them to the ;2 channel which is pushed into the bridge by
ast_unreal_channel_push_to_bridge().  The callbacks are called when the
specific channel leaves the bridging system.  Since the ;1 channel is
never put into a bridge the callbacks never get called.  The callbacks
then never remove the moh_wrapper from the app_bridges_moh container.  As
a result we cannot find the channel associated with the wrapper to start
MOH because it has hungup.  This is the reason causing the reported issue.

* Rather than using after bridge callbacks to cleanup, we now have
moh_channel_thread() doing the cleanup when the channel hangs up.

* Fixed moh_channel_thread() accumulating control frames on the stasis
bridge MOH channel until MOH is stopped.  Control frames are no longer
accumulated while MOH is playing.

* Fixed channel ref counting issue.  stasis_app_bridge_moh_channel() may
or may not return a channel ref.  As a result ast_ari_bridges_start_moh()
wouldn't know it may have a channel ref to release.
stasis_app_bridge_moh_channel() will now return a ref with the channel it
returns.

* Eliminated RAII_VAR in bridge_moh_create().

ASTERISK-26094 #close

Change-Id: Ibff479e167b3320c68aaabfada7e1d0ef7bd548c
res/ari/resource_bridges.c
res/res_stasis.c