[asterisk-dev] [Code Review] 3733: Added a pluggable module for pluggable_modules.py that allows the user to test different attributes of a given sound file

[Jonathan Rose]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/#review12693
-----------------------------------------------------------



/asterisk/trunk/lib/python/asterisk/pluggable_modules.py
<https://reviewboard.asterisk.org/r/3733/#comment22970>

    The opposite of a 'relative' path is actually called an 'absolute' path rather than a 'defined' path.


- Jonathan Rose


On July 9, 2014, 1:19 p.m., Christopher Wolfe wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3733/
> -----------------------------------------------------------
> 
> (Updated July 9, 2014, 1:19 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24010
>     https://issues.asterisk.org/jira/browse/ASTERISK-24010
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> Allows the user to test a recorded sound file in many different ways:
> 1) This test ALWAYS gets done- Checks whether the given sound file exists using a predefined path that can be created by either explicitly defining a filepath by declaring the filepath type as defined, or using a default path that is relative to the current test's var/spool/asterisk folder. From there, the user can add extensions to the file name to tack on relative folders (monitor/testaudio.wav being an example).
> 2) Optional- The sound file is checked whether it fits within a certain size criteria (measured in bytes).  A basis size and degree of size tolerance are determined by the user.  For example, if the size was 500000 and the tolerance was set to 50000, then the sound file's size would need to be somewhere between 450000 and 550000 in order to pass that test.
> 3) Optional- The sound file's sound energy levels are checked.  This is done by creating a Local channel that should get sent to a dialplan extension that should contain a BackgroundDetect application that fits the user's specifications. The variable that will be used to pass the sound file must be called SOUNDFILE, and a UserEvent must give off the name soundcheck in order for the event to be picked up.  A sample extension:
> [soundtest]
> exten => audio,1,Answer()
> same => n,Set(TALK_DETECTED=0)
> same => n,BackgroundDetect(${SOUNDFILE},1,20,,20000)
> same => n,GoToIf($[${TALK_DETECTED}=0]?pass:fail)
> same => n(fail),UserEvent(soundcheck, status: pass)
> same => n,Hangup()
> 
> same => n(pass),UserEvent(soundcheck, status: fail)
> same => n,Hangup()
> 
> A sound-file test only gets called when a specified trigger has gone off.  So far, this pluggable module only supports events as triggers.  The list of triggers matches to each instance of a sound-file test on a one-to-one basis (the first trigger starts the first test, and so on).
> Only passes after all tests specified by the user have been passed and the correct triggers have been received.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/apps/mixmonitor/testaudio2.raw UNKNOWN 
>   /asterisk/trunk/tests/apps/mixmonitor/testaudio1.raw UNKNOWN 
>   /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION 
>   /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5168 
> 
> Diff: https://reviewboard.asterisk.org/r/3733/diff/
> 
> 
> Testing
> -------
> 
> - Tried using the pluggable module by putting in incorrect input and purposefully leaving out input.  Picks those errors up.
> - Not sure if I was supposed to allow the user to name their own dialplan variable and Userevent name, so I left it as was.
> - Tested the different scenarios of setting the filepath- relative and defined.
> - Made sure the various tests could fail if a certain sound file didn't meet the size criteria or silence threshold criteria.
> - Made sure that more than one test could be run and that things could be run sequentially.
> 
> 
> Thanks,
> 
> Christopher Wolfe
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140716/253b09cb/attachment.html>