[asterisk-bugs] [JIRA] (ASTERISK-19049) CDR wasn't generated after doing redirect through AGI

Matt Jordan (JIRA) noreply at issues.asterisk.org
Thu Jan 9 20:15:03 CST 2014


    [ https://issues.asterisk.org/jira/browse/ASTERISK-19049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=213893#comment-213893 ] 

Matt Jordan commented on ASTERISK-19049:
----------------------------------------

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.
                
> CDR wasn't generated after doing redirect through AGI
> -----------------------------------------------------
>
>                 Key: ASTERISK-19049
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19049
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_cdr, CDR/General, Functions/func_cdr
>    Affects Versions: SVN, 1.8.7.2, 10.0.0-rc3
>         Environment: Linux Ubuntu 2.6.32-33-server, package from packages.asterisk.org, sources from packages.asterisk.org and from svn
>            Reporter: Martin Čechvala
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list