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

[Mark Michelson]

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


I'm not sure if you looked into it, but it is possible that you could combine your various phone B scenarios into a single scenario that just takes different inputs in order to determine how it constructs SDPs in the reinvites. It'll work like it is, but if nothing else, looking into combining the scenarios can give you some practice with SIPp hackery in order to get used to what all it can do.


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

    There's nothing "wrong" about using this $call variable, per se, but FYI SIPp has an easier inbuilt mechanism for doing this. If you place [service] where you currently have [$call] then you can control what gets placed there with the -s command line option for SIPp.



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

    You need to include a to-tag in this reinvite. I believe you can do this by setting the To header to
    
    To: phone_A <sip:phone_A@[remote_ip]>[peer_tag_param]
    
    Note that I also changed the user portion of the SIP URI to be phone_A instead of phone_B because I assume that was a copy and paste error. It's not essential to getting the test working though.



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

    You'll need a to-tag here as well. You also have phone_B as the user here.



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

    Need a to-tag



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

    Need a to-tag


- Mark


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/20130225/f89dbe0c/attachment-0001.htm>