[asterisk-dev] [Code Review]: Add test for subscribing for MWI notifications from external sources using a Test Object that manages SIPp scenarios

[Matt Jordan]

> On July 24, 2012, 5:48 p.m., Mark Michelson wrote:
> > This looks good and simple. I have two comments/suggestions
> > 
> > 1) It's unclear how the positional_arguments of a SIPpScenario would be configured. I'm unsure how I would configure -key options for a SIPp scenario.
> > 2) Consider a case where Asterisk initiates a call to a UAS. In such a case, we can't just launch the SIPp scenario since it will be waiting for a request from Asterisk. I suggest creating an additional type of observer callback that can be called when the scenario has been launched. This way, the callback can tell Asterisk to originate a call or do whatever it needs to do.
> > 3) The current test object doesn't have a way to run multiple scenarios at once. This can be useful for cases where a UAC scenario places a call through Asterisk to a UAS scenario. So it may be useful to be able to indicate that a group of scenarios should be run as a single unit simultaneously.
> > 
> > For suggestions 2 and 3, you may just say that those sort of things fall outside the scope of what you're trying to do here, and I'd be okay with it. It may be that someone writes a test object subclass of the one you have here in order to deal with those sorts of scenarios.

1) Yeah, there isn't a way of doing that.  To get around that, we'd need to split up the entry that represents a SIPp scenario into a dictionary with sub-dictionary/sequences:

- { key-arguments: { scenario: 'foo.xml'}, positional-arguments: ['-key', 'bar', 'blah'] }

That can be done easily.

2) In some ways, that's what the SIP SUBSCRIBE test is doing.  The SIPp scenario acts as the UAS and waits for the SUBSCRIBE request.  Typically, SIPp scenarios will just sit and wait for the request that triggers their actions - while they have a timeout, we usually pass it 20s by default.  That being said, the suggestion is a good one - it may be useful to trigger some additional action when the scenario is launched.  Adding an observer point to do that is trivial, so it may as well be done.

3) Doh.  That was actually more the intent of things declared at the same level - a SIPpScenarioSequence can handle the 'test iteration' types of things.  Since there's no need to have more the one sequence of things (at least that I can see), I'll refactor accordingly.


- Matt


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


On July 23, 2012, 11:23 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2059/
> -----------------------------------------------------------
> 
> (Updated July 23, 2012, 11:23 a.m.)
> 
> 
> Review request for Asterisk Developers and Mark Michelson.
> 
> 
> Summary
> -------
> 
> This test introduces a fairly straight forward test that covers Asterisk sending a SUBSCRIBE request for MWI notifications, and receiving a corresponding NOTIFY request from the external source.  This test does not attempt to cover the event system's dispensing of MWI notifications to Asterisk modules; rather it only attempts to cover chan_sip's responsibilities in sending a SIP SUBSCRIBE request/receiving a SIP NOTIFY request.
> 
> As part of this, a new test object was written for the pluggable framework that orchestrates SIPp scenarios against a single instance of Asterisk.  SIPp scenarios can be executed in a sequence, and in parallel.  The test object includes entry points for custom modules to register themselves as observers between SIPp scenario executions - either between any scenario executed in parallel, or between sets of scenarios executed in sequence.
> 
> 
> This addresses bugs ASTERISK-19827 and ASTERISK-19939.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19827
>     https://issues.asterisk.org/jira/browse/ASTERISK-19939
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/channels/SIP/subscribe/sipp/uas_subscribe_mwi.xml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/subscribe/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/tests.yaml 3348 
>   /asterisk/trunk/lib/python/asterisk/sipp.py 3325 
>   /asterisk/trunk/sample-yaml/sipptestcase-config.yaml.sample PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/subscribe/configs/ast1/sip.conf PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2059/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt
> 
>

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