> On Aug. 19, 2014, 12:29 p.m., opticron wrote: > > /branches/13/res/stasis/control.c, lines 824-826 > > <https://reviewboard.asterisk.org/r/3920/diff/2/?file=66624#file66624line824> > > > > Drop the explicit locks and use ast_softhangup() instead since it locks > > chan for you.
Actually, those two functions differ more than just locking the channel. - rmudgett ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3920/#review13118 ----------------------------------------------------------- On Aug. 19, 2014, 11:10 a.m., Mark Michelson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3920/ > ----------------------------------------------------------- > > (Updated Aug. 19, 2014, 11:10 a.m.) > > > Review request for Asterisk Developers. > > > 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 > ----- > > /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
