Summary:	ASTERISK-23295: ARI: ChannelEnteredBridge event not delivered to client during bridge move operation
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2014-02-13 10:43:03.000-0600	Date Closed:	2014-03-18 07:30:18
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_ari Tests/testsuite
Versions:	12.0.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ASTERISK-23295-testsuite-log.txt ( 1) full.txt.2
Description:	Note that this was caught by the bridges/move test in the Asterisk Test Suite. This test creates two bridges. It takes a channel in ARI, adds it to one bridge, then POSTs an addChannel to the second bridge. The expected result is that the channel leaves the first bridge and enters the second. In the attached log, we can see that the core did, in fact, do this, but that the second ChannelEnteredBridge event is never delivered to ARI. The Asterisk log shows the AMI events going out for this transaction, but the attached testsuite log shows that the ARI client never received the event.
Comments:	By: Kinsey Moore (kmoore) 2014-03-11 13:14:22.105-0500 I now understand why this happens and I may have a fix. The issue occurs because when a channel is added to a bridge, the subscription addition process occurs after queueing the channel to be added to the bridge. Under the right circumstances, the channel can get added before the main stasis app loop can process the change in bridges and the addition of the new subscription. The solution I'm working on involves adding an additional subscription to the bridge before the channel is queued. Unfortunately, this could become an issue if a channel leaves stasis without leaving a stasis bridge since it doesn't appear that a channel is departed from its stasis bridge upon exit from Stasis() (I haven't tested this yet). By: Kinsey Moore (kmoore) 2014-03-12 07:24:22.709-0500 Correction: The channel is actually departed from the bridge upon exit from Stasis() via the ari/channels/{id}/continue API call, so that isn't an issue. By: Kinsey Moore (kmoore) 2014-03-18 07:30:18.320-0500 This has been committed to 12 and trunk.