[asterisk-dev] [Code Review] Testsuite: Disallow MoH upon hold option

[opticron]

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


The findings on the XML call scenarios should be applied to all of the scenarios in this review.


/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_A.xml
<https://reviewboard.asterisk.org/r/2337/#comment15016>

    This is unnecessary and is overridden by the stream-level attribute.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_media_restrict.xml
<https://reviewboard.asterisk.org/r/2337/#comment15013>

    Picking out the Call-ID is unnecessary in this case. [call_id] or [last_Call-ID] will work for this purpose.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_media_restrict.xml
<https://reviewboard.asterisk.org/r/2337/#comment15014>

    This must include the same number of streams as were offered in the initial INVITE to be correct.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_media_restrict.xml
<https://reviewboard.asterisk.org/r/2337/#comment15015>

    You should expect receipt of a 200 OK anywhere you are sending a BYE unless you're explicitly expecting a different response code.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/test-config.yaml
<https://reviewboard.asterisk.org/r/2337/#comment15009>

    This should be reworded with regard to Josh's comment on https://reviewboard.asterisk.org/r/2336/.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/test-config.yaml
<https://reviewboard.asterisk.org/r/2337/#comment15010>

    This is a trunk-only change since it is a new feature.  This field should specify '12'.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/test-config.yaml
<https://reviewboard.asterisk.org/r/2337/#comment15011>

    To be consistent with other test tags, this should be SIP instead of sip.



/asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/test-config.yaml
<https://reviewboard.asterisk.org/r/2337/#comment15012>

    This is unnecessary unless you are using a test-specific module that exists only in this test directory.


- opticron


On Feb. 18, 2013, 2:30 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2337/
> -----------------------------------------------------------
> 
> (Updated Feb. 18, 2013, 2:30 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Tests to make sure the music on hold event is not triggered if the "discard_remote_hold_retrieval" option is set to "yes".  In the test multiple scenarios are ran where one SIP phone puts another SIP phone on hold by sending a re-INVITE with a modified SDP containing either a restricted audio direction, an IP address of 0.0.0.0, or a combination thereof.  This is tested both for a local RTP bridge, and a non-bridged scenario.
> 
> 
> This addresses bug ABE-2899.
>     https://issues.asterisk.org/jira/browse/ABE-2899
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/configs/ast1/sip.conf PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_A.xml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_IP_media_restrict.xml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_IP_restrict.xml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_media_restrict.xml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/tests.yaml 3642 
> 
> Diff: https://reviewboard.asterisk.org/r/2337/diff
> 
> 
> Testing
> -------
> 
> Ran the test and made sure all scenarios passed.  Also set the discard_remote_hold_retrieval to "no" and made sure the test failed. 
> 
> 
> Thanks,
> 
> Kevin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130221/98e2ca15/attachment-0001.htm>