Upgraded to FreePBX Distro with version 12 - now CDR duplicate records

I was running FreePBX Distro 5.211.65 and used the upgrade script to migrate to 6.12.65-20 and FreePBX 12 (using Asterisk 12). After applying all the module updates, etc., I noticed that the CDR started having multiple (duplicate) entries for every inbound call. At first I thought it was just the CDR frontend (a join or something). But was was logged into the Asterisk console and watching messages when I tested with another call. What I got there appears to be what looks like multiple inserts into CEL and CDR. I can understand multiple inserts into CEL for state changes, but the CDR inserts all appear to be identical:

   > [INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,userfield) VALUES ('HANGUP',{ts '2014-12-09 08:03:14'},'MARK J BAILEY','615YYYYYYY','615YYYYYYY','','615XXXXXXX','h','ext-group','SIP/vitel-inbound-0000001c','','',3,'','1418133786.160','1418133786.160','','','')]
   > [INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,userfield) VALUES ('CHAN_END',{ts '2014-12-09 08:03:14'},'MARK J BAILEY','615YYYYYYY','615YYYYYYY','','615XXXXXXX','h','ext-group','SIP/vitel-inbound-0000001c','','',3,'','1418133786.160','1418133786.160','','','')]
   > [INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,userfield) VALUES ('LINKEDID_END',{ts '2014-12-09 08:03:14'},'MARK J BAILEY','615YYYYYYY','615YYYYYYY','','615XXXXXXX','h','ext-group','SIP/vitel-inbound-0000001c','','',3,'','1418133786.160','1418133786.160','','','')]
   > [INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:06' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','778','ext-group','SIP/vitel-inbound-0000001c','SIP/2101-0000001d','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',8,8,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]
   > [INSERT INTO cdr (calldate,clid,src,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:10' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','SIP/vitel-inbound-0000001c','SIP/2864-0000001e','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',3,3,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]
   > [INSERT INTO cdr (calldate,clid,src,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:10' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','SIP/vitel-inbound-0000001c','SIP/2150-0000001f','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',3,3,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]
   > [INSERT INTO cdr (calldate,clid,src,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:10' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','SIP/vitel-inbound-0000001c','SIP/2549-00000020','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',3,3,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]
   > [INSERT INTO cdr (calldate,clid,src,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:10' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','SIP/vitel-inbound-0000001c','SIP/2548-00000021','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',3,3,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]
   > [INSERT INTO cdr (calldate,clid,src,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:10' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','SIP/vitel-inbound-0000001c','SIP/8501-00000022','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',3,3,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]
   > [INSERT INTO cdr (calldate,clid,src,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,uniqueid,recordingfile,did,cnum,cnam) VALUES ({ ts '2014-12-09 08:03:10' },'"MARK J BAILEY" <615YYYYYYY>','615YYYYYYY','SIP/vitel-inbound-0000001c','SIP/2190-00000023','Dial','SIP/2101&SIP/2864&SIP/2150&SIP/2120&SIP/2140&SIP/2549&SIP/2548&SIP/8501&SIP/219',3,3,'NO ANSWER',3,'1418133786.160','in-615XXXXXXX-615YYYYYYY-20141209-080306-1418133786.160.wav','615XXXXXXX','615YYYYYYY','MARK J BAILEY')]

I do use a ring group as indicated above.

This all started with the upgrade. I haven’t opened a ticket yet as I wanted to see if anyone else had experienced this. I have not tried to see what happens with a fresh install of 6.12.65 yet.

Thanks!

Mark

Yes, me too.

This can happen when upgrading between certain versions of FreePBX. You probably have duplicate entries in the files:

/etc/asterisk/logger_logfiles_additional.conf
/etc/asterisk/logger_logfiles_custom.conf

If so delete or comment the line(s) in the custom file.

Thanks, but that is not the case. I still have examples where I have 5, 6 or 7 of the same CDR entry.

Any other ideas?

Are you using Asterisk 12?

@tm1000, he is.

But, that’s actually legitimate, @jobsoftinc - have a look at the CDR.

A call was sent to a range of extensions, and that extension didn’t answer it. The 5th column (dstchannel) is different in each one, as each phone rang, and wasn’t answered.

This is more along the lines of ‘CDRs have changed in Asterisk 12’ and we don’t have a good way of displaying them.

But… how would YOU suggest we display a call that wasn’t answered?

1 Like

My reply was to @JessicaRabbit not the OP

@xrobau, that is what it looks like, and, if so, can you imagine the CDR records added for this single call if my ring group happened to have hundreds of extensions? I suspect you’re right in that this is a case of Asterisk 12 handling CDR differently. As a test, I suppose I could swap to Asterisk 11 and see if the behavior changes back to the way it was before. If it is something specific to Asterisk 12, then obviously the CDR report selection logic will need to be adjusted. I will try an earlier Asterisk and see what happens.

From

http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/asterisk-SysAdmin-SECT-1.html

maybe check that

unanswered = no

?

This is a change from Asterisk/Digium where-as for all the new infrastructure in Asterisk 12+ CDRs now monitor all local channels. There is no magic setting to revert it to the old way. A hangup between two calls will now show a hangup for each local channel. So 1 hangup event is really 2 because leg A and leg B both generate records. We have been through many discussions with Digium about this (too many to list or count).

Moving forward we are going to release a CEL module and depreciate CDRs.

1 Like

Yes, Asterisk 12. The responses are informative. I look forward to the solution, whatever it maybe.

Thanks

And the license on that upcoming CEL module?

The CEL module is a replacement for CDRs and will be released as Open Source

Cool deal! Looking forward to it. Any ETA?