[asterisk-dev] [Code Review] Make blind transfers not run the 'h' extension prematurely

[Mark Michelson]

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

Review request for Asterisk Developers.


Summary
-------

A recent change (rev 347595) caused channel technology-specific blind transfers to fail if the called channel transferred the calling channel, and the calling channel was in a context or macro with an h extension.

Presumably, there was a pre-existing problem since the h extension was being run on the transferee channel, and the transferee channel was not being hung up in the first place. Rather, the transferer (who does not have a PBX running on his channel) was the one being hung up. With the addition of setting the softhangup flag, the problem was compounded since the channel would be hung up unexpectedly.

My change is to examine the softhangup value on the channel when a bridge is broken and set the AST_FLAG_BRIDGE_HANGUP_DONT flag on the channel if the cause of the bridge breakage is for a "fake" hangup, such as an async goto. This makes it so the h extension is not run on a channel that's actually still alive, and it makes it so that blind transfers are once again fixed.

My only hesitation with just committing this is that it means that the h extension is no longer run in situations where it once was. However, in my opinion, it was buggy to be running the h extension since the channel was not actually being hung up.


This addresses bug ASTERISK-19173.
    https://issues.asterisk.org/jira/browse/ASTERISK-19173


Diffs
-----

  /branches/1.8/main/features.c 351501 

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


Testing
-------

Tested blind transfers using SIP phones. Worked for me. Asked reporter of ASTERISK-19173 for testing feedback as well.


Thanks,

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120120/54e46ef4/attachment.htm>