> On Jan. 14, 2015, 1:06 p.m., rmudgett wrote: > > /branches/13/apps/app_dial.c, line 2977 > > <https://reviewboard.asterisk.org/r/4336/diff/2/?file=70536#file70536line2977> > > > > Probably should set res9 and res on the gosub result conditions above > > then check res9 here since res may not be zero on entering the enclosing > > code block. > > Matt Jordan wrote: > I disagree. res9 is used to check the result of ast_app_exec_sub, and > shouldn't be repurposed. res is used to check the overall success/failure. > > The logic here should be correct. Even if res is non-zero upon entering > this block, if we had raised the dial event previously, we would have set > dial_end_raised. If we did not raise the dial end event previously, then > dial_end_raised is 0 and we properly raise a dial end here.
My point here was that the value of res may be nonzero before the gosub is run and not because of the GOSUB_RETVAL setting it to -1. In this case you could do a DialEnd with an unexpected gosub_result value. Look at the OPT_ANNOUNCE code above where it handles AST_FRAME_DTMF_END. ast_senddigit() could be changed to return a nonzero value that gets put into res. If you don't want to repurpose res9 then create res5 for want of another horrid variable name. :) - rmudgett ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4336/#review14185 ----------------------------------------------------------- On Jan. 14, 2015, 12:07 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4336/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2015, 12:07 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24682 > https://issues.asterisk.org/jira/browse/ASTERISK-24682 > > > Repository: Asterisk > > > Description > ------- > > The Dial application has some interesting options with the mid-call Macro (M) > and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific > values, the Dial application will take some action upon the channels involved > in the dial operation (such as hanging up a particular party, etc.) The Dial > application ensures that a Stasis message is published in the event that > MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so > that there is a corresponding DialEnd event published in AMI/ARI for the > DialBegin event that preceeded it. > > A bug exists where that same DialEnd event will be published on Stasis even > if the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial > application cares about. This causes two DialEnd events to be published - one > with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all > sorts of wrong. > > This patch fixes the bug by ensuring that we only publish a DialEnd message > to Stasis if the Dial application's mid-call Macro/GoSub returns something > that Dial cares about. > > > Diffs > ----- > > /branches/13/apps/app_dial.c 430607 > > Diff: https://reviewboard.asterisk.org/r/4336/diff/ > > > Testing > ------- > > See https://reviewboard.asterisk.org/r/4337 for tests. > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- 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
