[asterisk-dev] [Code Review] 3362: func_periodic_hook: New function for periodic hooks.

[Russell Bryant]

> 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 at 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140401/ccdca1e6/attachment-0001.html>