[asterisk-dev] [Code Review] 3525: Testsuite: Fix ARI attended transfer test

[opticron]

> On May 20, 2014, 12:34 p.m., Matt Jordan wrote:
> > I may be a bit dense on this, but I'm still confused as to what legs are getting transferred in this scenario.
> > 
> > You have two SIPp scenarios that are actually doing the REFER request and some portion of the attended transfer. Where are the other two call legs? If they are part of an already established Asterisk channel, which ones are getting replaced? Or are they doing the replacing?
> > 
> > A diagram would be _very_ helpful.

The other two call legs do not exist or are in the dialplan depending on how you want to look at it.

Summarized from the new description:
All channels are created:
Originated Channel -> Stasis()
SIPp #1 -> Stasis()
SIPp #2 -> Echo()

Test bridges channels in Stasis():
Originated Channel -> Stasis() -> ARI/Stasis bridge -> Stasis() -> SIPp #1
SIPp #2 -> Echo()

SIPp scenarios perform attended transfer:
Originated Channel -> Stasis() -> ARI/Stasis bridge -> Stasis() -> Local Channel -> Echo()

Remaining channels are hung up.


- opticron


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


On May 20, 2014, 1:37 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3525/
> -----------------------------------------------------------
> 
> (Updated May 20, 2014, 1:37 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.
> 
> 
> Diffs
> -----
> 
>   asterisk/trunk/tests/rest_api/bridges/attended_transfer/test-config.yaml 5043 
>   asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referer.xml PRE-CREATION 
>   asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referee.xml PRE-CREATION 
>   asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py 5043 
>   asterisk/trunk/contrib/sipp/transfer/referer.xml PRE-CREATION 
>   asterisk/trunk/contrib/sipp/transfer/referee.xml PRE-CREATION 
>   asterisk/trunk/contrib/sipp/table_of_contents 5043 
> 
> Diff: https://reviewboard.asterisk.org/r/3525/diff/
> 
> 
> Testing
> -------
> 
> Ensured that the test was operating as expected.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140520/9f4b1442/attachment.html>