[asterisk-dev] [Code Review] 3362: func_periodic_hook: New function for periodic hooks.
Corey Farrell
reviewboard at asterisk.org
Wed Apr 2 16:25:17 CDT 2014
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3362/#review11472
-----------------------------------------------------------
/trunk/funcs/func_periodic_hook.c
<https://reviewboard.asterisk.org/r/3362/#comment21198>
The xmldoc states that these parameters are required so I think it would be better to report failure if either are ast_strlen_zero.
I have tagged this issue here instead of the documentation since I don't agree with them having defaults. I would not object strongly if args.exten were optional / default "s", but only if the parameters were reordered to PERIODIC_INTERVAL(interval,context,exten). My preference is to require the caller to be explicit with all parameters.
/trunk/funcs/func_periodic_hook.c
<https://reviewboard.asterisk.org/r/3362/#comment21200>
I just had a thought about AMI (and ARI?) security. This function should be unavailable to users without originate permissions. I'm not aware of a way to require Originate permissions from someone who is using AMI to write to this function, so I think this might need to use ast_custom_function_register_escalating.
I am very sure with AMI access to read this function and channel events I could perform a DoS attack against the local system while harassing 1 or more individuals with a continuous stream of silent calls (they hangup one call, another call comes within 1 second). Normally a lack of permission to originate channels should prevent me from doing this.
- Corey Farrell
On April 1, 2014, 12:43 p.m., Russell Bryant wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3362/
> -----------------------------------------------------------
>
> (Updated April 1, 2014, 12:43 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 411583
>
> 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.
>
> [hooks]
>
> exten => beep,1,Answer()
> same => n,Verbose(1,Channel name: ${HOOK_CHANNEL})
> same => n,Verbose(1,Hook ID: ${HOOK_ID})
> same => n,Playback(beep)
>
> [test]
>
> exten => 100,1,Answer()
> same => n,Set(BEEP_ID=${PERIODIC_HOOK(hooks,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/20140402/7c681acd/attachment.html>
More information about the asterisk-dev
mailing list