[asterisk-bugs] [JIRA] (ASTERISK-21843) Failed Dial() in a call file does not post a CDR record

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-21843:
----------------------------------------

I hate to be the bearer of bad news, but I don't think this is an enhancement that should be made.

# First, the patch is for an improvement, not a bug. The way CDRs are behaving currently in 1.8/11 is by design. With the current implementation of CDRs, continuing on in the dialplan implies that the same CDR should be used. Since the call failed, the 'unanswered' logic kicks in and we only log a CDR to the registered backends if the 'unanswered' flag is set. Yes, the 'unanswered' flag is verbose, but it also gives you all of the information you need in situations like this. Assuming that CDRs can be consumed with no post-processing is usually an incorrect assumption.
## Even if the behavior in 1.8/11 is undesirable, which is quite possible, we don't make changes to CDR behavior in release branches.
# Putting a 'dstchannel' on a channel's CDR can bypass that logic, but it is also incorrect. Once it is continuing on in the dialplan, the channel does not have a destination channel. Read-only properties on a CDR are usually read-only properties for a reason - for example, you've now created a situation where billing records can be modified to no longer reflect the parties that were involved in the billing situation. I'm not convinced that's a good idea.
# Even if this patch were to be accepted, it would go into trunk. CDRs in trunk have been completely rewritten, so this patch wouldn't apply.
## CDRs in trunk are a reflection of the channels involved in a call. In general, a CDR completely reflects what the channels were actually doing; modifying the destination channel is therefore impossible, as the channel does not have a destination channel at that point in time.
## CDRs in trunk also don't necessarily behave the same with the 'continue in dialplan' option. CDRs in trunk are created for each path of communication between an endpoint and Asterisk or between two endpoints. It should therefore create a new CDR for the continue in dialplan portion, which means you probably won't run into the behavior in Asterisk 12+ in the first place.


                
> Failed Dial() in a call file does not post a CDR record
> -------------------------------------------------------
>
>                 Key: ASTERISK-21843
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21843
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Functions/func_cdr
>    Affects Versions: 11.4.0
>            Reporter: Richard Miller
>         Attachments: func_cdr.patch
>
>
> Ordinarily, a failed Dial() will post a CDR for the last destination in dial list.  However, in a call file using a local channel and the G option to proceed in the dial plan after dialing (to run an AGI which talks to a database), no CDR is posted for a failed call.  This can be worked around by setting unanswered=yes in cdr.conf, but that has undesirable side effects.  One example is that when calling multiple locations in a single Dial(), all the the destinations which did not end up participating in the call also get a CDR posted.  The reason is that the calling leg of the Local channel does not have CDR(dstchannel) set to anything.  CDR(dstchannel) is currently a read-only property.  A patch to func_cdr.c allows setting CDR(dstchannel) when it is empty.  The dial plan can then use this feature in the error handler after a failed Dial().

--
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