[asterisk-dev] [Code Review] bridging tests: call parking timeout (comebacktoorigin = yes)

[Mark Michelson]

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

Ship it!


- Mark


On Jan. 31, 2013, 1:16 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2306/
> -----------------------------------------------------------
> 
> (Updated Jan. 31, 2013, 1:16 p.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson and kmoore.
> 
> 
> Summary
> -------
> 
> Three calls tested against a comebacktoorigin = yes parkinglot.
> The first test calls and when it times out it calls back and gets answered then hungup.
> The second test calls and when it times out, it calls back and is left waiting for the dial timeout to occur
> The third test calls and when it times out, it calls back and gets a busy signal.
> 
> In each case, the disposition of the call is evaluated as well as how it continues in the dialplan.
> This test uses the failtoken concept that I introduced the other day as well.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_yes/Executioner.py PRE-CREATION 
>   /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_yes/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_yes/configs/ast1/features.conf PRE-CREATION 
>   /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_yes/configs/ast2/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_yes/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/bridge/parkcall_timeout/tests.yaml PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2306/diff
> 
> 
> Testing
> -------
> 
> Tested changes to expectations, changes to the dial plan, and changes the CDR test module to see how they would impact failures.  In every case, things went as I anticipated. We do need to update some documentation in features.conf.sample since it suggests that when the dial times out that the dial plan will advance to the 't' extension and this doesn't happen (and as far as I'm aware never happened).
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130208/358a22f8/attachment.htm>