-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3920/#review13110
-----------------------------------------------------------
{quote}
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.
{quote}
Let's make an issue for that and get it in the queue. I agree however - major
changes to the bridging framework that don't need to be made shouldn't be made
in a release branch.
- Matt Jordan
On Aug. 18, 2014, 1:23 p.m., Mark Michelson wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3920/
> -----------------------------------------------------------
>
> (Updated Aug. 18, 2014, 1:23 p.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
