[asterisk-dev] [Code Review] 4292: app_macro: Don't restore the calling location on a channel redirect.

[rmudgett]

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

(Updated Jan. 13, 2015, 12:06 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 430564


Bugs: ASTERISK-23850
    https://issues.asterisk.org/jira/browse/ASTERISK-23850


Repository: Asterisk


Description
-------

v11: If a channel redirect to a macro exten of a macro that is active happens, the redirect location doesn't get executed.  Instead the original macro location is restored and gets reexecuted.

v13: An additional effect happens if a parked call times out to an extension in the macro that parked the call then the macro is reexecuted instead of the expected park return location.

* Made not restore the macro calling location on an AST_SOFTHANGUP_ASYNCGOTO.

* Increased the locked channel range when setting up the macro execution environment to cover things that should be done while the channel is locked.

* Removed unnecessary NULL tests before calling ast_free() in _macro_exec().


Diffs
-----

  /branches/11/apps/app_macro.c 430058 

Diff: https://reviewboard.asterisk.org/r/4292/diff/


Testing
-------

On v11, redirected the calling channel to an extension in a macro that dialed the peer.  Before the patch, the peer was hung up and immediately redialed.  With the patch, the expected redirection location in the macro is executed.

On the v13 version of the patch, the parked call returns to the configured macro extension with the patch.  Without the patch, the call was immediately reparked.

Testsuite tests on review https://reviewboard.asterisk.org/r/4319/
Tests park_timeout_inside and redirect_inside fail when patch is not applied.  All four tests pass when patch is applied.


Thanks,

rmudgett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150113/8a3c2f8c/attachment.html>