[asterisk-dev] [Code Review] 3560: Testsuite: Add PJSIP nominal attended transfer tests
Matt Jordan
reviewboard at asterisk.org
Fri Jun 6 08:35:34 CDT 2014
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3560/#review12076
-----------------------------------------------------------
asterisk/trunk/contrib/sipp/table_of_contents
<https://reviewboard.asterisk.org/r/3560/#comment22072>
I'd add a note for both of these that, since they are the initiator of the sendCmd 3pcc command, they *must* be started after referee.xml has started.
asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/attended_transfer.py
<https://reviewboard.asterisk.org/r/3560/#comment22074>
Nitpick: most of the cleaned up files in the testsuite moved to using three """ for pydoc comments.
asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/attended_transfer.py
<https://reviewboard.asterisk.org/r/3560/#comment22075>
I'm not sure I understand why this is needed. The SIPp scenarios themselves should be able to govern when the channels are hung up.
asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/test-config.yaml
<https://reviewboard.asterisk.org/r/3560/#comment22076>
This won't work reliably with 3pcc.
The scenario that uses recvCmd *must* start before the scenario that uses sendCmd. This had to be fixed in the attended transfer tests used for ARI as well.
Since we will need to use this functionality a lot more in the future, I suggest a modification to the SIPp scenario management. This is going to be a little tricky however, since each entry in the list of scenarios is assumed to be the parameters that you pass directly to the SIPp scenario to launch. What's more, the entries in the list have to be launched in parallel, as many tests rely on that functionality.
Complicating this further, process management in twisted doesn't exactly make it easy to know for certain when a process has successfully kicked off.
I hacked around this previously by just starting the sendCmd scenario several seconds after the recvCmd scenario - but it feels like a more permanent solution would be appropriate.
How about we do the following:
(1) In the YAML, use the following nomenclature to define a 3pcc relationship between scenarios:
scenarios:
- { '3pcc':
{ 'recv-scenario': { 'key-args': ... },
{ 'send-scenario': { 'key-args': ... },
etc.
The following code will have to be modified in SIPpTestCase:
for defined_scenario_set in self._test_config['test-iterations']:
scenario_set = defined_scenario_set['scenarios']
# Build a list of SIPpScenario objects to run in parallel from
# each set of scenarios in the YAML config
sipp_scenarios = []
for scenario in scenario_set:
ordered_args = scenario.get('ordered-args') or []
target = scenario.get('target') or '127.0.0.1'
sipp_scenarios.append(SIPpScenario(self.test_name,
scenario['key-args'],
ordered_args,
target=target))
self.scenarios.append(sipp_scenarios)
I'd suggest subclassing SIPpScenario. Instead of having a single class manage a single process, we would instead of a SIPp3PCCScenario (which is a terrible name, so please come up with something better) that manages two SIPpScenarios - one being the receiver, one being the sender. It can be started in parallel with other scenarios, however, it should guarantee that the receiver scenario starts before the sender.
asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/tests.yaml
<https://reviewboard.asterisk.org/r/3560/#comment22073>
There's going to be a lot more attended transfer tests.
- Nominal remote attended transfers (https://issues.asterisk.org/jira/browse/ASTERISK-23699)
- Nominal remote target attended transfers (https://issues.asterisk.org/jira/browse/ASTERISK-23702)
- Nominal local attended transfers to an application (https://issues.asterisk.org/jira/browse/ASTERISK-23695)
- Nominal local attended transfer w/ Hold, REFER/Replaces (https://issues.asterisk.org/jira/browse/ASTERISK-23643)
- Off-nominal invalid remote destination (https://issues.asterisk.org/jira/browse/ASTERISK-23701)
- Off-nominal invalid local replaces (https://issues.asterisk.org/jira/browse/ASTERISK-23696)
So, to plan for the future, I'd rename these tests to be more explicit about the scenario being tested - maybe:
- 'caller_local_nominal'
- 'callee_local_nominal'
- Matt Jordan
On May 22, 2014, 3:20 p.m., opticron wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3560/
> -----------------------------------------------------------
>
> (Updated May 22, 2014, 3:20 p.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Bugs: ASTERISK-23643
> https://issues.asterisk.org/jira/browse/ASTERISK-23643
>
>
> Repository: testsuite
>
>
> Description
> -------
>
> This adds tests for nominal callee- and caller-initiated attended transfer scenarios using SIPp scenarios and SIPp's 3PCC to coordinate call state. This also adds another sample SIPp scenario for handling the REFER initiator behavior as a UAS that works with referee.xml (the UAC attended transfer coordinator).
>
>
> Diffs
> -----
>
> asterisk/trunk/tests/channels/pjsip/transfers/tests.yaml 5043
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/tests.yaml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/test-config.yaml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/sipp/uas.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/sipp/referer.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/sipp/referee.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/configs/ast1/pjsip.conf PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/configs/ast1/extensions.conf PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/caller_initiated/attended_transfer.py PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/test-config.yaml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/sipp/uas.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/sipp/uac-no-hangup.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/sipp/referer_uas.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/sipp/referee.xml PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/configs/ast1/pjsip.conf PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/configs/ast1/extensions.conf PRE-CREATION
> asterisk/trunk/tests/channels/pjsip/transfers/attended_transfer/callee_initiated/attended_transfer.py PRE-CREATION
> asterisk/trunk/contrib/sipp/transfer/referer_uas.xml PRE-CREATION
> asterisk/trunk/contrib/sipp/table_of_contents 5043
>
> Diff: https://reviewboard.asterisk.org/r/3560/diff/
>
>
> Testing
> -------
>
> Ensured that the tests performed as expected.
>
>
> Thanks,
>
> opticron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140606/b0b34fff/attachment-0001.html>
More information about the asterisk-dev
mailing list