]> 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:40:24 +0000 (18:40 -0500)
commitdfa926337cef99a5607e42423bd277445adaebe0
tree7dbdb651873eac0757123357861deb8bed1e5fd1
parenta0d5f45baa226ea6d4aa67edf0f01ab8346d4796
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