|Summary:||ASTERISK-21843: Failed Dial() in a call file does not post a CDR record|
|Reporter:||Richard Miller (ulogic)||Labels:|
|Date Opened:||2013-05-29 07:41:17||Date Closed:||2013-05-31 15:22:09|
|Environment:||Attachments:||( 0) func_cdr.patch|
|Description:||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().|
|Comments:||By: Walter Doekes (wdoekes) 2013-05-29 07:43:06.739-0500|
RFEs are refused unless they are accompanied by a patch.
And getting changes done to the CDR system is well.. not likely to happen. Have you consider switching to CEL logging instead?
By: Richard Miller (ulogic) 2013-05-29 07:45:42.842-0500
This patch allows
same => n,Set(CDR(dstchannel)=my_destination)
when CDR(dstchannel) is empty
By: Richard Miller (ulogic) 2013-05-29 07:54:48.714-0500
I am using both CDR and CEL logging. However, the CDR is more concise and less verbose.
By: Matt Jordan (mjordan) 2013-05-29 09:24:33.170-0500
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.
By: Richard Miller (ulogic) 2013-05-29 10:21:46.798-0500
Thank you for your explanation.
The patch does not allow you to modify a record where the dstchannel is already populated. It is not intended to abuse the CDR posting mechanism. The patch works for me in this particular situation. If it does not make it into production releases, I can live with maintaining this patch for myself. I am using this in a production environment and am not ready to experiment with a beta version of 12 at this time.
By: Rusty Newton (rnewton) 2013-05-31 15:22:09.700-0500
Closing out in regards to Mjordan's comments. We won't change CDR behavior any further in the currently supported branches and it won't apply to CDR in 12.
@Richard Miller, despite this not working out for inclusion, thanks for reporting and providing a patch!