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] 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/#review12955 --- /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23338 s/app/API call/ /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23339 put both in quotes since this sentence seems a bit off otherwise. /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23340 Red blob. /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23341 Red blob. /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23342 s/application/API call/ Add quotes to in. /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23344 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. /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23343 s/application/API call/ /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml https://reviewboard.asterisk.org/r/3872/#comment23345 The same comment about silence applies here. - opticron On July 30, 2014, 11:21 a.m., Christopher Wolfe wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3872/ --- (Updated July 30, 2014, 11:21 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 /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] 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
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, 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 -- _ -- 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/#review12960 --- This test unfortunately doesn't work on my box and after discussing it with cwolfe, I think it'll be bouncy on Panda. We probably need to re-evaluate our approach to this. - Jonathan Rose 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 -- _ -- 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
