----------------------------------------------------------- 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@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 > >
-- _____________________________________________________________________ -- 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
