----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3525/#review11877 -----------------------------------------------------------
I feel like we're missing a SIPp scenario here. We have the initial receiver of the call, and we have the scenario that sends the REFER request - but where is the second SIP channel from the initiator of the transfer, and where is the destination of the transfer? asterisk/trunk/lib/python/asterisk/ari.py <https://reviewboard.asterisk.org/r/3525/#comment21759> This should not be bundled with EventWatcher. Separation of concerns takes a real beating when you combine SIPp related activities with a general callback function executor. I would structure this differently: 1) Have a generic base class that provides event matching and calls a virtual method when an event matches. 2) Extract out the existing callback functionality and place it into a concrete class that inherits from the base class. 3) Add your SIPp scenario execution in another concrete class. 4) Modify WebSocketEventModule to look at the config passed to it and instantiate the object based on the type specified in the yaml. You can do this either by using factory functions (based on a passed in string keyword), or by dynamically instantiating the object in the same fashion as test_runner.py. asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/call_echo.xml <https://reviewboard.asterisk.org/r/3525/#comment21760> Echo Leg doesn't make much sense. I'd name these scenarios in a fashion that fits with a more typical 'call' nomenclature. That would make it easier to map the scenarios back to the test description. Note that these scenarios should get copied into our sample YAML folder when approved, as they should be able to be used as a basis for other attended transfer tests. asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/call_echo.xml <https://reviewboard.asterisk.org/r/3525/#comment21762> Use a set of consistent From/To users in these tests. If the test participants are alice, bob, and charlie - then by all means use them as your various user portions in the SIP URIs. 1000 and Bob currently have no relation to "Echo Leg". asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/call_stasis.xml <https://reviewboard.asterisk.org/r/3525/#comment21764> This is a lie :-P asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/call_stasis.xml <https://reviewboard.asterisk.org/r/3525/#comment21763> Same findings here asterisk/trunk/tests/rest_api/bridges/attended_transfer/test-config.yaml <https://reviewboard.asterisk.org/r/3525/#comment21761> This description is woefully inadequate, particularly with the complexity of the impending SIPp scenarios :-) This should: * List the scenarios involved, and who initiates the transfer * How the transfer is kicked off * What expected results should occur - Matt Jordan On May 9, 2014, 2:13 p.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3525/ > ----------------------------------------------------------- > > (Updated May 9, 2014, 2:13 p.m.) > > > Review request for Asterisk Developers and Joshua Colp. > > > Bugs: ASTERISK-23641 > https://issues.asterisk.org/jira/browse/ASTERISK-23641 > > > Repository: testsuite > > > Description > ------- > > This reworks a significant portion of the ARI attended transfer test to avoid > dependence on pjsua since it has the tendency to cause sporadic (and > sometimes consistent) test failures. The reworked test uses SIPp with 3PCC to > manage the transfer scenario. > > This change also gives WebSocketEventModule (and anything else using > EventMatcher) the ability to spawn SIPp scenarios in response to websocket > events. > > > Diffs > ----- > > asterisk/trunk/tests/rest_api/bridges/attended_transfer/test-config.yaml > 5020 > > asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/call_stasis.xml > PRE-CREATION > asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/call_echo.xml > PRE-CREATION > > asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py > 5020 > asterisk/trunk/lib/python/asterisk/ari.py 5020 > > Diff: https://reviewboard.asterisk.org/r/3525/diff/ > > > Testing > ------- > > Ensured that the test was operating as expected. > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
