> On March 31, 2014, 5:58 p.m., Corey Farrell wrote: > > /trunk/funcs/func_periodic_hook.c, lines 141-143 > > <https://reviewboard.asterisk.org/r/3362/diff/6/?file=56951#file56951line141> > > > > Macro is deprecated, why not use Gosub? > > Russell Bryant wrote: > I tried that. GoSub() doesn't actually work in this case. Perhaps > because there's no PBX running on the channel? In any case, that's why. > > rmudgett wrote: > I haven't checked, but would calling this be appropriate here to avoid > the adding the need for Macro back into the code: > int ast_app_exec_sub(struct ast_channel *autoservice_chan, struct > ast_channel *sub_chan, const char *sub_args, int ignore_hangup) > > > Russell Bryant wrote: > Awesome. That sounds like the API call needed here. > > Russell Bryant wrote: > Well ... it's not *that* straight forward. GoSub (or Macro) is being > used as one side of an originated call. I'd have to add a new application to > make it work. GoSubInternal (for internal use only) or something. > > Any preference between just using Macro vs adding a new GoSubInternal app? > > I know Macro is considered deprecated but it does work fine here. > Besides, Macro has been around *so* long (10+ years?), removing it would just > be evil. > > rmudgett wrote: > Macro has been removed from being a requirement of Asterisk core and is > deprecated. It needs to go away. It sounds like you are originating to an > application which is a Macro. Why not just originate to an exten since that > seems to be what Macro is doing for you. > > Russell Bryant wrote: > It's originating with dialplan on both ends of the call. Macro is used > on one end as a way to run dialplan, but also pass arguments (variables) to > that dialplan. Earlier revs of the patch originated to an extension > directly, but with that I couldn't pass variables to that dialplan (channel > name and hook ID right now). > > BTW, somewhat unrelated, I think removing Macro() is a terrible idea. > I'd be all for re-implementing it using GoSub internally, but removing a > syntax that has been supported for 10+ years, breaking countless examples on > the internet, does not seem worth it. > > Russell Bryant wrote: > Actually ... maybe this should work without using GoSub or Macro? I'm > passing variables in already via the originate API call, but I was only > expecting them to be available to the dialplan running behind the Local > channel for some reason. Maybe they're available on both sides of the Local > channel? I'll have to test it out.
Um, yes. It works. I can drop the usage of Macro() or GoSub() completely. Oops. - Russell ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/#review11455 ----------------------------------------------------------- On March 31, 2014, 8:33 p.m., Russell Bryant wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3362/ > ----------------------------------------------------------- > > (Updated March 31, 2014, 8:33 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > This commit introduces a new dialplan function, PERIODIC_HOOK(). > It allows you run to a dialplan hook on a channel periodically. The > original use case that inspired this was the ability to play a beep > periodically into a call being recorded. The implementation is much > more generic though and could be used for many other things. > > The implementation makes heavy use of existing Asterisk components. > It uses a combination of Local channels and ChanSpy() to run some > custom dialplan and inject any audio it generates into an active call. > > The other important bit of the implementation is how it figures out > when to trigger the beep playback. This implementation uses the > audiohook API, even though it's not actually touching the audio in any > way. It's a convenient way to get a callback and check if it's time > to kick off another beep. It would be nice if this was timer event > based instead of polling based, but unfortunately I don't see a way to > do it that won't interfere with other things. > > > Diffs > ----- > > /trunk/funcs/func_periodic_hook.c PRE-CREATION > /trunk/CHANGES 411572 > > Diff: https://reviewboard.asterisk.org/r/3362/diff/ > > > Testing > ------- > > Called the following extension (100@test), both letting it run all the way > through, as well as hanging up at various points in the middle. > > > [macro-beep] > > exten => s,1,Answer() > same => n,Verbose(1,Channel name: ${ARG1}) > same => n,Verbose(1,Hook ID: ${ARG2}) > same => n,Playback(beep) > > [test] > > exten => 100,1,Answer() > same => n,Set(BEEP_ID=${PERIODIC_HOOK(beep,5)}) > same => n,Wait(20) > same => n,Set(PERIODIC_HOOK(${BEEP_ID})=off) > same => n,Wait(20) > same => n,Set(PERIODIC_HOOK(${BEEP_ID})=on) > same => n,Wait(20) > same => n,Hangup() > > > Thanks, > > Russell Bryant > >
-- _____________________________________________________________________ -- 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
