----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3920/ -----------------------------------------------------------
(Updated Aug. 19, 2014, 4:10 p.m.) Review request for Asterisk Developers. Changes ------- Added Richard's suggested edit. Repository: Asterisk Description ------- When a channel is moved from a Stasis bridge to a non-Stasis bridge, the behavior after the non-Stasis bridge dissolves is incorrect. The issue is that since channels are imparted into Stasis bridges as departable rather than independent, control of the channel returns to the main Stasis application loop after the non-Stasis bridge dissolves. From the end-user perspective, this is most odd. As an example, say that Alice calls into Stasis and is placed into a Stasis bridge. Bob places a call into the dialplan and calls Bridge(Alice,x), requesting to be bridged with Alice and requesting that Alice be hung up if Bob hangs up first. Alice is pulled from the Stasis, is sent a StasisEnd event, and is pushed into the non-Stasis bridge created by the Bridge application. If Bob were to hang up, the expectation would be that Alice's channel would be hung up as well. However, in actuality, Alice remains in the Stasis application and must be hung up manually. Expecations of Alice's post-bridge destination are also not met when passing the 'F' option or no options at all to the Bridge application. This patch aims to correct the unexpected behavior by detecting the circumstances when Alice's channel leaves the bridging system. If Alice has already had a StasisEnd published when leaving the bridging system, then Stasis's after bridge callback will attempt to direct Alice to where she is intended to go. To be honest, I'm not a huge fan of this patch, but it gets the job done. The proper way to fix the issue is to devise a method such that channels that enter Stasis bridges are not departable. However, such a change is of larger scope and risk than is acceptable for Asterisk 12 or 13 (in my judgment anyway), so I have gone with the patch seen here. For Asterisk 14, I would recommend a mini-project to make channels in Stasis bridges independent so that the correct behavior is taken care of innately by the bridging system instead. Diffs (updated) ----- /branches/13/res/stasis/control.c 421326 Diff: https://reviewboard.asterisk.org/r/3920/diff/ Testing ------- I created a small ARI application that places any channel that enters the app into a Stasis bridge. I then had a second channel call an extension in the dialplan that called the Bridge application to move the original channel into a non-Stasis bridge. I tested with several options passed to the Bridge application. With the patch, the following occurred: Bridge(Alice): Channel re-entered Stasis when the non-Stasis bridge dissolved. Bridge(Alice,F): Channel moved to the priority after the Bridge() application when the non-Stasis bridge dissolved. Bridge(Alice,x): Channel was hung up after the non-Stasis bridge dissolved. Thanks, Mark Michelson
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
