[asterisk-dev] [Code Review] 2476: Restore behavior of CDRs in blind transfers by preventing 'h' extension execution after testing of AST_FLAG_BRIDGE_HANGUP_DONT

[Matt Jordan]

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

(Updated April 27, 2013, 2:32 a.m.)


Review request for Asterisk Developers and Mark Michelson.


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


Repository: Asterisk


Description
-------

Yes, CDRs, yes, it's in a release branch.

Unfortunately, we accidentally changed the behavior of CDRs in 1.8 (specifically 1.8.9.0) in ASTERISK-19173, and this patch restores the previous behavior. So we're still within the ballpark of 'don't touch CDRs in a release branch' - we're trying *not* to touch them here.

ASTERISK-19173 looked to prevent the 'h' extension from being executed on channels in a blind transfer by setting the AST_FLAG_BRIDGE_HANGUP_DONT flag. It did this when it first detected the hangup frame. Unfortunately, setting this flag that early has other side effects - namely, it blows out the bridge_cdr information, removing the billing record information for the channel while it was in the bridge. Whoops.

Since we still have to avoid executing the 'h' extension, we look at the soft hangup flags before execution of said extension and skip it if the flags are set. This should preserve the behavior this patch intended to fix, while restoring the pre-1.8.9.0 behavior of CDRs.


Diffs
-----

  /branches/1.8/main/features.c 386724 

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


Testing
-------

Tested by Steve Davies (who wrote the patch) and Ishfaq Malik, who reported the issue. TestSuite also ran and passed.


Thanks,

Matt Jordan

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