Summary:	ASTERISK-24501: ARI: Moving a channel between bridges followed by a hangup can cause an ARI client to not receive an expected ChannelLeftBridge event before StasisEnd
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2014-11-05 19:55:15.000-0600	Date Closed:	2014-11-13 09:46:07.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_ari
Versions:	12.6.1 13.0.0	Frequency of Occurrence
Related Issues:	causes ASTERISK-24537 Stasis: StasisStart/StasisEnd events are not reliably transmitted during transfers
Environment:		Attachments:	( 0) full.txt
Description:	Consider the following scenario: * Channel 1 enters into Bridge A * An {{addChannel}} command is issued to add the channel to Bridge B * A bridge move operation begins to happen internally. * While the bridge move operation occurs, a {{DELETE /channel/1}} occurs. This queues a hangup on the channel, causing it to be removed from Bridge B. * We receive a StasisEnd event, followed by the ChannelLeftBridge event, which is wrong. This is shown in the attached log, which was produced from the Asterisk Test Suite {{/bridges/move}} test (which is sporadically failing due to this issue).
Comments:	By: Kinsey Moore (kmoore) 2014-11-07 11:07:20.454-0600 This is happening because the ChannelLeftBridge message is traversing the Stasis message bus while the StasisEnd message is being sent directly to the app in question. By: Matt Jordan (mjordan) 2014-11-07 11:11:22.821-0600 Why do we have different topics? There should be a single topic for an application. That would guarantee synchronization of all messages that the application cares about. By: Kinsey Moore (kmoore) 2014-11-07 11:13:56.033-0600 That's the problem, the normal StasisEnd sending is skipping topics altogether and calling app_send directly. By: Matt Jordan (mjordan) 2014-11-07 11:42:56.533-0600 Egads! By: Kinsey Moore (kmoore) 2014-11-10 14:47:46.541-0600 Apparently StasisStart messages have a similar problem and delayed removal of certain datastores related to masquerade detection cause StasisEnd messages to get swallowed when Stasis() is called in quick succession. These are the cause of the bouncing/failing tests I saw after I fixed StasisEnd.