[Home]

Summary:ASTERISK-19049: CDR wasn't generated after doing redirect through AGI
Reporter:Martin Čechvala (kveri)Labels:
Date Opened:2011-12-15 01:36:10.000-0600Date Closed:2014-01-09 20:14:50.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_cdr CDR/General Functions/func_cdr
Versions:SVN 1.8.7.2 10.0.0-rc3 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Linux Ubuntu 2.6.32-33-server, package from packages.asterisk.org, sources from packages.asterisk.org and from svnAttachments:
Description:I received a call from uplink to one of the extensions. Then I use AMI and send:
Action: Redirect
Channel: SIP/uplink-000000 (source channel)
Context: auto-answer
Exten: 7000 (original called destination extension)
Priority: 1

auto-answer context:
exten => 7000,1,SIPAddHeader(Call-Info: <sip:0.0.0.0>\;answer-after=0) ; similar header for other phones
exten => 7000,n,Dial(SIP/7000,30)
exten => 7000,n,Hangup

Auto-answer context is for automatic phone pickup, it just inserts SIP header and calls the same phone.
Phone is linksys, it accepts the call and everything works, but after hangup there is no CDR.

I located the issue in main/features.c:4262. There is a comment "QUESTION: should we copy bridge_cdr fields to the peer before we throw it away?". Well, that's causing this problem.

A temporarily (but really wrong) workaround is to replace
ast_cdr_discard(bridge_cdr);
with
ast_cdr_end(bridge_cdr);
ast_cdr_detach(bridge_cdr);

printing CDR here solves this issue, but I think it raises other hidden issues.
Comments:By: Matt Jordan (mjordan) 2014-01-09 20:14:38.356-0600

That particular piece of code in features.c exists, unfortunately, for a reason. The {{bridge_cdr}} is a CDR that holds the state of the CDR of the original channel before it goes into a bridge. This CDR is compared to the CDR on that channel after the bridging is complete in an attempt to output the correct information if the channel is masqueraded out of the bridge. In your particular case, the {{AST_FLAG_BRIDGE_HANGUP_DONT}} flag has been set, which means the channel will continue on in the dialplan. Because the channel is going to continue on in the dialplan, the {{bridge_cdr}} should be moot.

Unfortunately, changing this code is dangerous: it's part of handling CDRs in blind and attended transfers, which is notoriously bitter. As such, we don't make changes in this code in release branches.

At the same time, we have overhauled CDRs in Asterisk 12. The behaviour is substantially different. Because CDRs in Asterisk 12 listen for events over the Stasis message bus, they will pick up the Dial/Bridge between the endpoints and always generate a CDR. This issue should not happen in Asterisk 12 and later versions.

As such, I'm going to close out this issue as "Fixed" with a version of 12.0.0.
By: Gabriel Ortiz Lour (elbriga) 2016-06-01 12:58:56.591-0500

Just for the record, for those who are still using 1.8 and 11:

Instead the AMI "Redirect" action, use AMI "Command" action:
Action: Command
Command: channel redirect $chan $context,$exten,$prio

Works as expected and generates the CDR