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

[opticron]

> On Feb. 21, 2013, 4:59 p.m., opticron wrote:
> > /asterisk/trunk/tests/channels/SIP/sip_hold_no_moh/sipp/phone_B_media_restrict.xml, lines 8-14
> > <https://reviewboard.asterisk.org/r/2337/diff/1/?file=33505#file33505line8>
> >
> >     Picking out the Call-ID is unnecessary in this case. [call_id] or [last_Call-ID] will work for this purpose.
> 
> Matt Jordan wrote:
>     I'm not sure they will work in this scenario. If I recall correctly, [call_id] generates a different Call-ID then the received INVITE request, which makes the subsequent INVITE request that the scenario sends a different dialog. You can try [last_Call-ID], but I vaguely remember that SIPp doesn't handle re-INVITEs properly in this regard.
>     
>     It's possible I'm wrong so it's worth trying, but when I first wrote the SIPp hold tests I spent quite awhile hacking around on the Call-ID trying to get the re-INVITE to work.

I double-checked http://svn.digium.com/svn/testsuite/asterisk/trunk/tests/channels/SIP/session_timers/basic_uac_refresh/sipp/uas-no-hangup.xml and it seems to be operating as expected.  It uses [last_Call-ID] throughout, but only accepts reinvites and does not initiate them so it's a slightly different use case.


- opticron


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


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/20130222/543e13ef/attachment-0001.htm>