----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3900/#review13080 -----------------------------------------------------------
/branches/12/main/channel.c <https://reviewboard.asterisk.org/r/3900/#comment23522> double parens ((...)) /branches/12/main/framehook.c <https://reviewboard.asterisk.org/r/3900/#comment23523> _nolock version /branches/12/main/framehook.c <https://reviewboard.asterisk.org/r/3900/#comment23524> _nolock version - rmudgett On Aug. 11, 2014, 4:15 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3900/ > ----------------------------------------------------------- > > (Updated Aug. 11, 2014, 4:15 p.m.) > > > Review request for Asterisk Developers, Matt Jordan and rmudgett. > > > Bugs: ASTERISK-24027 > https://issues.asterisk.org/jira/browse/ASTERISK-24027 > > > Repository: Asterisk > > > Description > ------- > > An odd little issue that can interrupt features and even hangup calls > entirely in an unwanted fashion. > > Reproduction is fairly trivial, simply have a dynamic bridge feature that > plays audio or executes an AGI or something that just generally takes a > little while and is sensitive to hangups. > Call into an extension that puts that feature on the channel and call another > device. > Execute the feature. > While the feature is running, start mixmonitor on the channel executing the > feature and watch as the feature is prematurely terminated and the call > itself is hung up entirely. > > Having the flag to re-evaluate the status of the bridge be a hangup flag > seems to have been a little off point and trying to have everything that pays > attention to hangups specifically ignore it seems a little wacky, so instead > I've pulled AST_SOFTHANGUP_UNBRIDGE out of the soft hangup flags and turned > it into its own thing. > > > Diffs > ----- > > /branches/12/main/pbx.c 420558 > /branches/12/main/framehook.c 420558 > /branches/12/main/channel_internal_api.c 420558 > /branches/12/main/channel.c 420558 > /branches/12/main/bridge_channel.c 420558 > /branches/12/main/bridge_after.c 420558 > /branches/12/include/asterisk/channel.h 420558 > /branches/12/apps/app_stack.c 420558 > /branches/12/apps/app_mixmonitor.c 420558 > /branches/12/apps/app_chanspy.c 420558 > > Diff: https://reviewboard.asterisk.org/r/3900/diff/ > > > Testing > ------- > > Performed the above reproduction steps with the patch and the call no longer > hangs up and the feature completes normally. Mixmonitor captures all the > audio as well. > Made sure native RTP bridges would still be re-evaluated and become simple > bridges when a hook such as mixmonitor is placed on one of the bridged > channels. > Ran through chan_sip and chan_pjsip testsuite tests to make sure the patch > didn't introduce any failures. > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- 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
