[Home]

Summary:ASTERISK-27165: CDR: CDR(start,u) function won't work in cdr_custom config
Reporter:Jacek Konieczny (jkonieczny)Labels:
Date Opened:2017-07-31 04:00:48Date Closed:2017-09-07 10:42:48
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:CDR/cdr_custom
Versions:14.6.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:We have been using:
{noformat}
${CSV_QUOTE(${STRFTIME(${CDR(start,u)},GMT,%Y-%m-%d %H:%M:%S)})}
{noformat}

in out cdr_custom config to force GMT timestamps in the CDR.

This used to work properly with Asterisk 13. Recently, most probably after upgrade to Asterisk 14, instead of returning proper date this shows some unexpected '1970-01-01' timestamps.

To check what exactly is failing I have tried:
{noformat}
[mappings]
Master.csv => ${CDR(start)},${CDR(start,u)},${STRFTIME(${CDR(start,u)},GMT,%Y-%m-%d %H:%M:%S)},${CSV_QUOTE(${STRFTIME(${CDR(start,u)},GMT,%Y-%m-%d %H:%M:%S)})}
{noformat}

And got CDR records like these:
{noformat}
2017-07-31 10:27:16,2017-07-31 10:27:16,1970-01-01 00:33:37,"1970-01-01 00:33:37"
2017-07-31 10:30:47,2017-07-31 10:30:47,1970-01-01 00:33:37,"1970-01-01 00:33:37"
2017-07-31 10:30:46,2017-07-31 10:30:46,1970-01-01 00:33:37,"1970-01-01 00:33:37"
2017-07-31 10:30:43,2017-07-31 10:30:43,1970-01-01 00:33:37,"1970-01-01 00:33:37"
{noformat}

Please note how the second field is a 'human-readable' date instead of unformatted timestamp we should get using the 'u' option.

I have also tried to use the CDR(start,u) function in the dialplan:
{noformat}
exten => 200,1,Answer
exten => 200,n,Verbose(1,Parsed: ${CDR(start)})
exten => 200,n,Verbose(1,Unparsed: ${CDR(start,u)})
{noformat}

… and, strangely enough, it worked properly:

{noformat}
Parsed: 2017-07-31 10:57:34
Unparsed: 1501491454.043537
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2017-07-31 04:00:51.567-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Jacek Konieczny (jkonieczny) 2017-09-05 07:44:33.582-0500

I have submitted a patch to Gerrit fixing the 'u' flag when used in cdr_custom. 'f' flag still won't work, but properly fixing that would not be that trivial and 'u' should be enough in most use cases anyway.
By: Friendly Automation (friendly-automation) 2017-09-07 10:42:49.916-0500

Change 6460 merged by Jenkins2:
func_cdr: honour 'u' flag on dummy channel

[https://gerrit.asterisk.org/6460|https://gerrit.asterisk.org/6460]
By: Friendly Automation (friendly-automation) 2017-09-07 11:02:16.981-0500

Change 6461 merged by Jenkins2:
func_cdr: honour 'u' flag on dummy channel

[https://gerrit.asterisk.org/6461|https://gerrit.asterisk.org/6461]
By: Friendly Automation (friendly-automation) 2017-09-07 11:05:43.872-0500

Change 6388 merged by Joshua Colp:
func_cdr: honour 'u' flag on dummy channel

[https://gerrit.asterisk.org/6388|https://gerrit.asterisk.org/6388]
By: Friendly Automation (friendly-automation) 2017-09-07 11:15:28.556-0500

Change 6428 merged by Jenkins2:
func_cdr: honour 'u' flag on dummy channel

[https://gerrit.asterisk.org/6428|https://gerrit.asterisk.org/6428]