[asterisk-dev] [Code Review] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)

opticron reviewboard at asterisk.org
Fri Aug 1 15:00:22 CDT 2014



> On Aug. 1, 2014, 9:34 a.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.
> 
> Christopher Wolfe wrote:
>     Adding a delay does not change the results.  Playing back a silence of a short duration adds another ChannelTalkingDetected event.

Please upload a diff with the silence played between the two other prompts. I questioned the ChannelTalkingDetected count of 2 because previous tests had received 2 of these events for a playback of only the first prompt and here you're expecting 2 of these events for a playback of the first prompt AND a playback of the second prompt.


- opticron


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


On Aug. 1, 2014, 11:24 a.m., Christopher Wolfe wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3872/
> -----------------------------------------------------------
> 
> (Updated Aug. 1, 2014, 11:24 a.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 
> 
> 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
> 
>

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


More information about the asterisk-dev mailing list