stasis transfer: fix stasis bridge push race part two
authorScott Griepentrog <sgriepentrog@digium.com>
Thu, 29 Jan 2015 23:03:14 +0000 (23:03 +0000)
committerScott Griepentrog <sgriepentrog@digium.com>
Thu, 29 Jan 2015 23:03:14 +0000 (23:03 +0000)
commit388d691f34d7cfcb77130965bf8709eee4b692c1
tree1b9064d7cc66b65ea4918d2765845ebbdeb5ba8e
parentf61c80a8f7b30af0551167e6fe59d9e9c005f60d
stasis transfer: fix stasis bridge push race part two

When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread.  This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.

To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer.  Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.

ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
........

Merged revisions 431450 from http://svn.asterisk.org/svn/asterisk/branches/13

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
include/asterisk/bridge.h
main/bridge.c
res/stasis/stasis_bridge.c