Re: [asterisk-dev] [Code Review] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3872/ --- (Updated Aug. 29, 2014, 2:25 p.m.) Status -- This change has been discarded. Review request for Asterisk Developers. Bugs: ASTERISK-24094 https://issues.asterisk.org/jira/browse/ASTERISK-24094 Repository: testsuite Description --- Shows what happens when a Local channel's first half is muted (in the both, in, and out directions) and playback occurs in one of 4 ways: 1) Both channel halves play back a sound. 2) The first (muted) half plays back a sound only. 3) The second (unmuted) half plays back a sound only 4) Both channel halves play back a sound, the first channel half gets unmuted and then both channels play back again (shows that unmuting works). Uses a TALK_DETECT hook to check whether muting has occurred or not. Because muting was more powerful than expected, the conditions listed in the issue do not match what actually is being checked in the test. Diffs - /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3872/diff/ Testing --- Verified that TalkingEvents happened inside the log files. For some reason, the ChannelTalkingStart events of AMI didn't accurately show whether talking had occurred on a channel, so those event checkers were scrapped. The ARI ChannelTalkingStarted events were more accurate. Made sure that channels have both entered Stasis before starting a test. Only deletes a channel after playback is done. This is so that the results aren't fudged. It was discovered during testing that muting is overzealous, so the test just shows what happens in certain muting events. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3842: Tests the forward and reverse playback ARI functions for both channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3842/ --- (Updated Aug. 14, 2014, 3:27 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5448 Bugs: ASTERISK-24092 https://issues.asterisk.org/jira/browse/ASTERISK-24092 Repository: testsuite Description --- Test 1: Puts a local channel half into Stasis, and then plays back a sound on it (tt-monkeys). Upon starting the sound, the playback gets reversed using /control?operation=reverse and a TestEvent gets released that signifies a reversal has occurred. Test 2: Same thing as Test 1 except that you are using the /control?operation=forward ARI command and looking for a FastForward TestEvent. Test 3: Same thing as Test 1 except that a channel gets put into a bridge, and the bridge instead is the one that starts the playback. Test 4: Same thing as Test 3 except that you are testing the /control?operation=forward command on the bridge. Diffs - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/channels/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3842/diff/ Testing --- Made sure that expected values were received. These tests were pretty straightforward otherwise. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3796: Added tests to check whether accountcodes and LinkedIds propagated when two channels are put in a mixing bridge, but not in a holding bridge
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3796/ --- (Updated Aug. 12, 2014, 3:17 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5434 Bugs: ASTERISK-24003 https://issues.asterisk.org/jira/browse/ASTERISK-24003 Repository: testsuite Description --- One test checks whether or not when two channels with accountcodes are stored in a mixing bridge, that the accountcode of one channel gets stored in the other's peeraccount, and that the LinkedId of the channel that entered the bridge first replaces the LinkedId of the bridge that entered last. The other checks that the above conditions do NOT happen when two channels (one with an accountcode and one without) enter a holding bridge. Diffs - /asterisk/trunk/tests/rest_api/bridges/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/no_id_propagate/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/no_id_propagate/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/id_propagate/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/id_propagate/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3796/diff/ Testing --- Verified that expected values showed up in the Asterisk log files. Made conditions that verified that the last step occurred properly in order to progress the test. Compared the channels that entered the bridge with one that didn't. Originally had a python code approach, but then used strictly YAML and ari pluggable modules. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3839: Added a test to check the duration and energy_duration values of an ARI recording
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3839/ --- (Updated Aug. 12, 2014, 3:12 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Bugs: ASTERISK-24037 https://issues.asterisk.org/jira/browse/ASTERISK-24037 Repository: testsuite Description --- Test checks whether the duration and energy_duration of a recording created in ARI are both valid. One local channel half in ARI plays back 2 seconds worth of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), and then plays the first sound again. The other local channel half records these sounds as they are played. The total duration of the recorded sound file should be 6 seconds, while the energy_duration should be 4 seconds. When this gets verified, the SoundChecker pluggable module gets called and the sound file's size (should be around 96,000 bytes) gets verified, as well as the sound file's energy levels using BackgroundDetect. Since the SoundChecker pluggable module hasn't received a Ship It! yet, a dependency has been added accordingly. Diffs - /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3839/diff/ Testing --- Checked whether the recording object did return the correct values in the log files. One bottleneck to finishing this test was the fact that you had to add maxSilenceSeconds in the recording request in order to make energy_detection work AT ALL. Other than that, this test was pretty straightforward and easy to write. Thanks, Christopher Wolfe -- _ -- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated Aug. 12, 2014, 3 p.m.)
Status
--
This change has been marked as submitted.
Review request for Asterisk Developers.
Changes
---
Committed in revision 5431
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
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.
- All tests are done sequentially (with the first element in the list being
triggered first) and not asynchronous, unlike other pluggable modules.
Thanks,
Christopher Wolfe
--
_
-- 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
Re: [asterisk-dev] [Code Review] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3872/ --- (Updated Aug. 1, 2014, 4:24 p.m.) Review request for Asterisk Developers. Changes --- Fixed naming and syntax. Couldn't find anything wrong with my results for how many ChannelTalkingEvents I got, but I could be wrong. Bugs: ASTERISK-24094 https://issues.asterisk.org/jira/browse/ASTERISK-24094 Repository: testsuite Description --- Shows what happens when a Local channel's first half is muted (in the both, in, and out directions) and playback occurs in one of 4 ways: 1) Both channel halves play back a sound. 2) The first (muted) half plays back a sound only. 3) The second (unmuted) half plays back a sound only 4) Both channel halves play back a sound, the first channel half gets unmuted and then both channels play back again (shows that unmuting works). Uses a TALK_DETECT hook to check whether muting has occurred or not. Because muting was more powerful than expected, the conditions listed in the issue do not match what actually is being checked in the test. Diffs (updated) - /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3872/diff/ Testing --- Verified that TalkingEvents happened inside the log files. For some reason, the ChannelTalkingStart events of AMI didn't accurately show whether talking had occurred on a channel, so those event checkers were scrapped. The ARI ChannelTalkingStarted events were more accurate. Made sure that channels have both entered Stasis before starting a test. Only deletes a channel after playback is done. This is so that the results aren't fudged. It was discovered during testing that muting is overzealous, so the test just shows what happens in certain muting events. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)
> On Aug. 1, 2014, 2:34 p.m., opticron wrote: > > /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml, line > > 371 > > <https://reviewboard.asterisk.org/r/3872/diff/1/?file=65759#file65759line371> > > > > It seems odd that this is not 3. Can this be attributed to the fact > > that the audio restarts so quickly that Asterisk never perceives talking to > > have stopped? > > > > If that's the case, a short duration of silence may be required for > > this test to operate properly on slow machines. Adding a delay does not change the results. Playing back a silence of a short duration adds another ChannelTalkingDetected event. > On Aug. 1, 2014, 2:34 p.m., opticron wrote: > > /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml, > > line 364 > > <https://reviewboard.asterisk.org/r/3872/diff/1/?file=65761#file65761line364> > > > > The same comment about silence applies here. Same comment above. - Christopher --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3872/#review12955 --- On July 30, 2014, 4:21 p.m., Christopher Wolfe wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3872/ > --- > > (Updated July 30, 2014, 4:21 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24094 > https://issues.asterisk.org/jira/browse/ASTERISK-24094 > > > Repository: testsuite > > > Description > --- > > Shows what happens when a Local channel's first half is muted (in the both, > in, and out directions) and playback occurs in one of 4 ways: > 1) Both channel halves play back a sound. > 2) The first (muted) half plays back a sound only. > 3) The second (unmuted) half plays back a sound only > 4) Both channel halves play back a sound, the first channel half gets unmuted > and then both channels play back again (shows that unmuting works). > Uses a TALK_DETECT hook to check whether muting has occurred or not. > Because muting was more powerful than expected, the conditions listed in the > issue do not match what actually is being checked in the test. > > > Diffs > - > > /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 > /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION > /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf > PRE-CREATION > /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf > PRE-CREATION > /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf > PRE-CREATION > /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/3872/diff/ > > > Testing > --- > > Verified that TalkingEvents happened inside the log files. > For some reason, the ChannelTalkingStart events of AMI didn't accurately show > whether talking had occurred on a channel, so those event checkers were > scrapped. The ARI ChannelTalkingStarted events were more accurate. > Made sure that channels have both entered Stasis before starting a test. > Only deletes a channel after playback is done. This is so that the results > aren't fudged. > It was discovered during testing that muting is overzealous, so the test just > shows what happens in certain muting events. > > > Thanks, > > Christopher Wolfe > > -- _ -- 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
[asterisk-dev] [Code Review] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3872/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24094 https://issues.asterisk.org/jira/browse/ASTERISK-24094 Repository: testsuite Description --- Shows what happens when a Local channel's first half is muted (in the both, in, and out directions) and playback occurs in one of 4 ways: 1) Both channel halves play back a sound. 2) The first (muted) half plays back a sound only. 3) The second (unmuted) half plays back a sound only 4) Both channel halves play back a sound, the first channel half gets unmuted and then both channels play back again (shows that unmuting works). Uses a TALK_DETECT hook to check whether muting has occurred or not. Because muting was more powerful than expected, the conditions listed in the issue do not match what actually is being checked in the test. Diffs - /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3872/diff/ Testing --- Verified that TalkingEvents happened inside the log files. For some reason, the ChannelTalkingStart events of AMI didn't accurately show whether talking had occurred on a channel, so those event checkers were scrapped. The ARI ChannelTalkingStarted events were more accurate. Made sure that channels have both entered Stasis before starting a test. Only deletes a channel after playback is done. This is so that the results aren't fudged. It was discovered during testing that muting is overzealous, so the test just shows what happens in certain muting events. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3842: Tests the forward and reverse playback ARI functions for both channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3842/ --- (Updated July 30, 2014, 3:27 p.m.) Review request for Asterisk Developers. Changes --- Changed the order of deletion. Bugs: ASTERISK-24092 https://issues.asterisk.org/jira/browse/ASTERISK-24092 Repository: testsuite Description --- Test 1: Puts a local channel half into Stasis, and then plays back a sound on it (tt-monkeys). Upon starting the sound, the playback gets reversed using /control?operation=reverse and a TestEvent gets released that signifies a reversal has occurred. Test 2: Same thing as Test 1 except that you are using the /control?operation=forward ARI command and looking for a FastForward TestEvent. Test 3: Same thing as Test 1 except that a channel gets put into a bridge, and the bridge instead is the one that starts the playback. Test 4: Same thing as Test 3 except that you are testing the /control?operation=forward command on the bridge. Diffs (updated) - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/channels/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3842/diff/ Testing --- Made sure that expected values were received. These tests were pretty straightforward otherwise. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3839: Added a test to check the duration and energy_duration values of an ARI recording
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3839/ --- (Updated July 25, 2014, 5:44 p.m.) Review request for Asterisk Developers. Changes --- Since, the pluggable_module in Review Request 3733 changed in the auto-stop variable, this test's YAML had to be changed accordingly. Bugs: ASTERISK-24037 https://issues.asterisk.org/jira/browse/ASTERISK-24037 Repository: testsuite Description --- Test checks whether the duration and energy_duration of a recording created in ARI are both valid. One local channel half in ARI plays back 2 seconds worth of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), and then plays the first sound again. The other local channel half records these sounds as they are played. The total duration of the recorded sound file should be 6 seconds, while the energy_duration should be 4 seconds. When this gets verified, the SoundChecker pluggable module gets called and the sound file's size (should be around 96,000 bytes) gets verified, as well as the sound file's energy levels using BackgroundDetect. Since the SoundChecker pluggable module hasn't received a Ship It! yet, a dependency has been added accordingly. Diffs (updated) - /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3839/diff/ Testing --- Checked whether the recording object did return the correct values in the log files. One bottleneck to finishing this test was the fact that you had to add maxSilenceSeconds in the recording request in order to make energy_detection work AT ALL. Other than that, this test was pretty straightforward and easy to write. Thanks, Christopher Wolfe -- _ -- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 25, 2014, 5:41 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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
Diff: https://reviewboard.asterisk.org/r/3733/diff/
Testing (updated)
---
- 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.
- All tests are done sequentially (with the first element in the list being
triggered first) and not asynchronous, unlike other pluggable modules.
Thanks,
Christopher Wolfe
--
_
-- 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
Re: [asterisk-dev] [Code Review] 3842: Tests the forward and reverse playback ARI functions for both channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3842/ --- (Updated July 24, 2014, 5:44 p.m.) Review request for Asterisk Developers. Changes --- Made the correct issue appear under the Bugs section. Bugs: ASTERISK-24092 https://issues.asterisk.org/jira/browse/ASTERISK-24092 Repository: testsuite Description --- Test 1: Puts a local channel half into Stasis, and then plays back a sound on it (tt-monkeys). Upon starting the sound, the playback gets reversed using /control?operation=reverse and a TestEvent gets released that signifies a reversal has occurred. Test 2: Same thing as Test 1 except that you are using the /control?operation=forward ARI command and looking for a FastForward TestEvent. Test 3: Same thing as Test 1 except that a channel gets put into a bridge, and the bridge instead is the one that starts the playback. Test 4: Same thing as Test 3 except that you are testing the /control?operation=forward command on the bridge. Diffs - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/channels/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3842/diff/ Testing --- Made sure that expected values were received. These tests were pretty straightforward otherwise. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3842: Tests the forward and reverse playback ARI functions for both channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3842/ --- (Updated July 24, 2014, 5:42 p.m.) Review request for Asterisk Developers. Changes --- Addressed dependency and test finishing issues. Bugs: SWP-7157 https://issues.asterisk.org/jira/browse/SWP-7157 Repository: testsuite Description --- Test 1: Puts a local channel half into Stasis, and then plays back a sound on it (tt-monkeys). Upon starting the sound, the playback gets reversed using /control?operation=reverse and a TestEvent gets released that signifies a reversal has occurred. Test 2: Same thing as Test 1 except that you are using the /control?operation=forward ARI command and looking for a FastForward TestEvent. Test 3: Same thing as Test 1 except that a channel gets put into a bridge, and the bridge instead is the one that starts the playback. Test 4: Same thing as Test 3 except that you are testing the /control?operation=forward command on the bridge. Diffs (updated) - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/channels/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3842/diff/ Testing --- Made sure that expected values were received. These tests were pretty straightforward otherwise. Thanks, Christopher Wolfe -- _ -- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 24, 2014, 5:08 p.m.)
Review request for Asterisk Developers.
Changes
---
Sample yaml was misleading in the setting of the auto-stop variable.
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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 (updated)
-
/asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
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
--
_
-- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 24, 2014, 3:53 p.m.)
Review request for Asterisk Developers.
Changes
---
Cleaned up code better / remove extraneous statements.
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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 (updated)
-
/asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
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
--
_
-- 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
Re: [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
> On July 24, 2014, 2:22 p.m., Matt Jordan wrote:
> > /asterisk/trunk/lib/python/asterisk/pluggable_modules.py, lines 430-431
> > <https://reviewboard.asterisk.org/r/3733/diff/5/?file=65065#file65065line430>
> >
> > I'm not sure why you're popping 'type' off of the action here.
The reason why I do this is because if you do the method that you recommended,
namely ami.originate(**action), it doesn't like the type variable that is
listed under the action dictionary. So this is kind of neccessary.
- Christopher
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/#review12853
-------
On July 22, 2014, 6:46 p.m., Christopher Wolfe wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3733/
> ---
>
> (Updated July 22, 2014, 6:46 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 50 and the
> tolerance was set to 5, then the sound file's size would need to be
> somewhere between 45 and 55 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,,2)
> 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/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
> /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
>
> 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
>
>
--
_
-- 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
Re: [asterisk-dev] [Code Review] 3842: Tests the forward and reverse playback ARI functions for both channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3842/ --- (Updated July 23, 2014, 6:23 p.m.) Review request for Asterisk Developers. Bugs: SWP-7157 https://issues.asterisk.org/jira/browse/SWP-7157 Repository: testsuite Description --- Test 1: Puts a local channel half into Stasis, and then plays back a sound on it (tt-monkeys). Upon starting the sound, the playback gets reversed using /control?operation=reverse and a TestEvent gets released that signifies a reversal has occurred. Test 2: Same thing as Test 1 except that you are using the /control?operation=forward ARI command and looking for a FastForward TestEvent. Test 3: Same thing as Test 1 except that a channel gets put into a bridge, and the bridge instead is the one that starts the playback. Test 4: Same thing as Test 3 except that you are testing the /control?operation=forward command on the bridge. Diffs - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/channels/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/forward/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/playback/reverse/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/reverse/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/forward/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3842/diff/ Testing --- Made sure that expected values were received. These tests were pretty straightforward otherwise. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3839: Added a test to check the duration and energy_duration values of an ARI recording
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3839/ --- (Updated July 23, 2014, 5:26 p.m.) Review request for Asterisk Developers. Changes --- Added talking_duration and silence_duration, changed the version, and added some more dependencies. Bugs: ASTERISK-24037 https://issues.asterisk.org/jira/browse/ASTERISK-24037 Repository: testsuite Description --- Test checks whether the duration and energy_duration of a recording created in ARI are both valid. One local channel half in ARI plays back 2 seconds worth of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), and then plays the first sound again. The other local channel half records these sounds as they are played. The total duration of the recorded sound file should be 6 seconds, while the energy_duration should be 4 seconds. When this gets verified, the SoundChecker pluggable module gets called and the sound file's size (should be around 96,000 bytes) gets verified, as well as the sound file's energy levels using BackgroundDetect. Since the SoundChecker pluggable module hasn't received a Ship It! yet, a dependency has been added accordingly. Diffs (updated) - /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3839/diff/ Testing --- Checked whether the recording object did return the correct values in the log files. One bottleneck to finishing this test was the fact that you had to add maxSilenceSeconds in the recording request in order to make energy_detection work AT ALL. Other than that, this test was pretty straightforward and easy to write. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3839: Added a test to check the duration and energy_duration values of an ARI recording
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3839/ --- (Updated July 22, 2014, 8:59 p.m.) Review request for Asterisk Developers. Changes --- For some reason, the dependency was removed. Bugs: ASTERISK-24037 https://issues.asterisk.org/jira/browse/ASTERISK-24037 Repository: testsuite Description --- Test checks whether the duration and energy_duration of a recording created in ARI are both valid. One local channel half in ARI plays back 2 seconds worth of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), and then plays the first sound again. The other local channel half records these sounds as they are played. The total duration of the recorded sound file should be 6 seconds, while the energy_duration should be 4 seconds. When this gets verified, the SoundChecker pluggable module gets called and the sound file's size (should be around 96,000 bytes) gets verified, as well as the sound file's energy levels using BackgroundDetect. Since the SoundChecker pluggable module hasn't received a Ship It! yet, a dependency has been added accordingly. Diffs - /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3839/diff/ Testing --- Checked whether the recording object did return the correct values in the log files. One bottleneck to finishing this test was the fact that you had to add maxSilenceSeconds in the recording request in order to make energy_detection work AT ALL. Other than that, this test was pretty straightforward and easy to write. Thanks, Christopher Wolfe -- _ -- 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
Re: [asterisk-dev] [Code Review] 3839: Added a test to check the duration and energy_duration values of an ARI recording
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3839/ --- (Updated July 22, 2014, 8:57 p.m.) Review request for Asterisk Developers. Changes --- Changed the variable name to match the current state made by the patch. Bugs: ASTERISK-24037 https://issues.asterisk.org/jira/browse/ASTERISK-24037 Repository: testsuite Description --- Test checks whether the duration and energy_duration of a recording created in ARI are both valid. One local channel half in ARI plays back 2 seconds worth of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), and then plays the first sound again. The other local channel half records these sounds as they are played. The total duration of the recorded sound file should be 6 seconds, while the energy_duration should be 4 seconds. When this gets verified, the SoundChecker pluggable module gets called and the sound file's size (should be around 96,000 bytes) gets verified, as well as the sound file's energy levels using BackgroundDetect. Since the SoundChecker pluggable module hasn't received a Ship It! yet, a dependency has been added accordingly. Diffs (updated) - /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3839/diff/ Testing --- Checked whether the recording object did return the correct values in the log files. One bottleneck to finishing this test was the fact that you had to add maxSilenceSeconds in the recording request in order to make energy_detection work AT ALL. Other than that, this test was pretty straightforward and easy to write. Thanks, Christopher Wolfe -- _ -- 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
[asterisk-dev] [Code Review] 3839: Added a test to check the duration and energy_duration values of an ARI recording
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3839/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24037 https://issues.asterisk.org/jira/browse/ASTERISK-24037 Repository: testsuite Description --- Test checks whether the duration and energy_duration of a recording created in ARI are both valid. One local channel half in ARI plays back 2 seconds worth of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), and then plays the first sound again. The other local channel half records these sounds as they are played. The total duration of the recorded sound file should be 6 seconds, while the energy_duration should be 4 seconds. When this gets verified, the SoundChecker pluggable module gets called and the sound file's size (should be around 96,000 bytes) gets verified, as well as the sound file's energy levels using BackgroundDetect. Since the SoundChecker pluggable module hasn't received a Ship It! yet, a dependency has been added accordingly. Diffs - /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3839/diff/ Testing --- Checked whether the recording object did return the correct values in the log files. One bottleneck to finishing this test was the fact that you had to add maxSilenceSeconds in the recording request in order to make energy_detection work AT ALL. Other than that, this test was pretty straightforward and easy to write. Thanks, Christopher Wolfe -- _ -- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 22, 2014, 6:46 p.m.)
Review request for Asterisk Developers.
Changes
---
Never mind. Now it's fixed.
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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 (updated)
-
/asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
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
--
_
-- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 22, 2014, 6:20 p.m.)
Review request for Asterisk Developers.
Changes
---
Due to a silly programming error, you actually had to specify the AMI id in the
main sound_file part of the YAML. This has now been fixed. Also removed a
print statement that was used mainly for self-testing.
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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 (updated)
-
/asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
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
--
_
-- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 21, 2014, 9:38 p.m.)
Review request for Asterisk Developers.
Changes
---
Fixed various syntatical and naming issues. Tried to remove indexes but doing
so was deemed impossible with how this pluggable module is set up.
Restructured how data is accessed in order to make this pluggable module appear
more consistent with the others.
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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 (updated)
-
/asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION
/asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249
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
--
_
-- 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
Re: [asterisk-dev] [Code Review] 3796: Added tests to check whether accountcodes and LinkedIds propagated when two channels are put in a mixing bridge, but not in a holding bridge
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3796/ --- (Updated July 17, 2014, 7:29 p.m.) Review request for Asterisk Developers. Changes --- Fixed consistency issues. Bugs: ASTERISK-24003 https://issues.asterisk.org/jira/browse/ASTERISK-24003 Repository: testsuite Description --- One test checks whether or not when two channels with accountcodes are stored in a mixing bridge, that the accountcode of one channel gets stored in the other's peeraccount, and that the LinkedId of the channel that entered the bridge first replaces the LinkedId of the bridge that entered last. The other checks that the above conditions do NOT happen when two channels (one with an accountcode and one without) enter a holding bridge. Diffs (updated) - /asterisk/trunk/tests/rest_api/bridges/tests.yaml 5249 /asterisk/trunk/tests/rest_api/bridges/no_id_propagate/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/no_id_propagate/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/id_propagate/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/id_propagate/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3796/diff/ Testing --- Verified that expected values showed up in the Asterisk log files. Made conditions that verified that the last step occurred properly in order to progress the test. Compared the channels that entered the bridge with one that didn't. Originally had a python code approach, but then used strictly YAML and ari pluggable modules. Thanks, Christopher Wolfe -- _ -- 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
[asterisk-dev] [Code Review] 3796: Added tests to check whether accountcodes and LinkedIds propagated when two channels are put in a mixing bridge, but not in a holding bridge
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3796/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24003 https://issues.asterisk.org/jira/browse/ASTERISK-24003 Repository: testsuite Description --- One test checks whether or not when two channels with accountcodes are stored in a mixing bridge, that the accountcode of one channel gets stored in the other's peeraccount, and that the LinkedId of the channel that entered the bridge first replaces the LinkedId of the bridge that entered last. The other checks that the above conditions do NOT happen when two channels (one with an accountcode and one without) enter a holding bridge. Diffs - /asterisk/trunk/tests/rest_api/bridges/tests.yaml 5242 /asterisk/trunk/tests/rest_api/bridges/no_id_propagate/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/no_id_propagate/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/id_propagate/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/id_propagate/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3796/diff/ Testing --- Verified that expected values showed up in the Asterisk log files. Made conditions that verified that the last step occurred properly in order to progress the test. Compared the channels that entered the bridge with one that didn't. Originally had a python code approach, but then used strictly YAML and ari pluggable modules. Thanks, Christopher Wolfe -- _ -- 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
Re: [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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
(Updated July 9, 2014, 6:19 p.m.)
Review request for Asterisk Developers.
Changes
---
Added testing done
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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 (updated)
---
- 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
--
_
-- 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
[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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3733/
---
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 50 and the tolerance
was set to 5, then the sound file's size would need to be somewhere between
45 and 55 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,,2)
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
---
Thanks,
Christopher Wolfe
--
_
-- 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
