CDR Reports - One call, two entries

Disclaimer: I will be the first to admit that I am really very new with FreePBX, Asterisk, and SIP in general; from zero to now in about half a week. But I’ve googled and googled, and just can’t seem to find anything.


I am currently running FreePBX on Solaris with success. I have now installed, and can successfully see call logs in the Reports section. However, I see duplicate entries for outbound calls to the PSTN via an SIP trunk from a third-party provider, which are placed and connected.

For example, from a soft-phone on this computer I dial 918001234567. The outbound line is picked up (9) and 1-800-123-4567 is dialed. The phone rings, my friend answers it, and we talk for a few minutes. One of us hangs up.

In Reports->Call Logs, I now see something like…

  1.  2008-10-31 02:14:59  	SIP/202-08...  	8009876543  	8009876543  	918001234567  	NO ANSWER  	00:00
  2.  2008-10-31 02:09:24 	SIP/202-08... 	8009876543 	8009876543 	918001234567 	ANSWERED 	05:35

…where 918001234567 is what I dial and 8009876543 is my DID/phone number.

Why is there a second log entry of type NO ANSWER with zero time? This does not happen with internal, extension-to-extension calls, or on an inbound call from the PSTN.



Same problem here, since upgrade from a trunk version of february to asterisk
I can see from the logging that there are duplicate calls to cdr logging. I don’t think therefore that it has something to do with the cdr module itself. I think it must be something with the dialplans but i can’t figure out what.

Hope that somebody else can shed some more light on your question.

I changed following part of extensions.conf from:

; What to do on hangup. [macro-hangupcall] exten => s,1,ResetCDR(w) exten => s,n,NoCDR()

; What to do on hangup. [macro-hangupcall] exten => s,n,NoCDR()
Now only the correct entry is being generated.
Since the code will be replaced by the original version when applying changes from the GUI, i still have to figure out how to make the change persistent.

I can’t make any guarantees, but I THINK this might work. Docs are fairly slim on this.

Open extensions.conf and copy select that part of the file beginning with

; What to do on hangup.

through the end of that section ending with the line


Copy this selection to a file called extensions_override_freepbx.conf in the /etc/asterisk directory.

Edit this new file to reflect the changes you describe.

Reload Asterisk.

The way I understand it, the contents of the override file will supercede any content in the other extensions files.

As I said, I’m probably wrong on this, so if it doesn’t work, deleting the override file will return tour system to normal.


I have seen other posts regarding this as well. Not sure what the answer is- could use some help from someone smarter than me. These are both working test boxes, willing to try or hand over the reigns via ssh to a dev or someone smarter than me for testing if need be, just say the word. Let me know if you need more information.

Basic configuration:

Asterisk 1.4.22 x86_64 with MySQL Version: 5.0.45 asterisk and asteriskcdr databases running on a different server. FreePBX, Core, all running on CentOS 5.2. Fresh install, yum updates for all as of tonight. Using SIP trunks (no registration on the SIP trunks btw) no DAHDI hardware and G729 on the trunk. ztdummy installed and running according to zttool. SIP user agent is configured device/user rather than the default extension. Testing below was performed with CounterPath EyeBeam Version build 42237, also using G729.

Some more information:

Asterisk -r CLI output:

experimental001*CLI> cdr status
CDR logging: enabled
CDR mode: simple
CDR output unanswered calls: no
CDR registered backend: csv
CDR registered backend: cdr_manager
CDR registered backend: cdr-custom
CDR registered backend: mysql

experimental001*CLI> cdr mysql status
Connected to [email protected] using table cdr for 49 minutes, 40 seconds.
Wrote 10 records since last restart.

CDR Output:

(this was one call that lasted 16 seconds to my cell phone. Last 4 digits of the destination number X’d out)
2008-11-06 03:12:04 SIP/550199… 8005551212 8005551212 303378xxxx NO ANSWER 00:00
2008-11-06 03:11:48 SIP/550199… 8005551212 8005551212 303378xxxx ANSWERED 00:16

(another call, 13 seconds long, to my cell phone)
2008-11-06 03:11:26 SIP/550199… 8005551212 8005551212 303378xxxx NO ANSWER 00:00
2008-11-06 03:11:13 SIP/550199… 8005551212 8005551212 303378xxxx ANSWERED 00:13

Asterisk box:
[[email protected] asterisk]# uname -r

[[email protected] freepbx-2.5.1]# uname -r

Thanks for your suggestion, just tried it but could not get it to work.
I tried placing an adjusted copy of the [macro-hangupcall] section, successively in extensions_override_freepbx.conf and extensions_custom.conf but the original definition of [macro-hangupcall] was not being overruled by any of those.

After re-applying the modification to [macro-hangupcall] of extensions.conf, the second CDR entry is skipped again.
I will leave it this way for the moment, since re-generating the files from the GUI does not seem to affect the modification.

Of course, other suggestions are welcome.

Well, I guess i misunderstood how the override file worked…


Putting it into the extensions_override_freepbx.conf file is the proper place to put it.

But just putting it into the file is not enough. Once the changes are placed in that file and saves you need to reload asterisk so that it re-reads the configuration files and see’s the changes.

I wonder if he realoded asterisk? So…for future reference…my suggestions should work?


yes, once the dialplan is reloaded it should work. (has in the past for me) when I’ve modified the hangup routines.

Yes, sure he reloaded asterisk :wink:

I even forced the freepbx reconfiguration by making an simple modification to one of the extensions, pushed the submit button and confirmed the question to continue the reload.
I did that because i wanted to check if making changes from the GUI would reverse the adjustments i manually made previously to extensions.conf.

But i will try and redo the steps and post the conclusion.



This drove me crazy and was not allowing me to properly report on call data due to the duplicate entries - even after following the instructions on this thread I was unsuccessful and was still getting duplicate entries. I added the following to my extensions_override_freepbx.conf and did a reload and was still getting duplicate CDR entries.

; What to do on hangup. 
exten => s,n,NoCDR()

After reading around I worked it out it turns out that the code fragment isn’t quite right, though extremely close. The solution that finally worked for me was to place in extensions_override_freepbx.conf the following line

; What to do on hangup. 
exten => s,1,NoCDR()

A dialplan item, like an extension of a macro, or a whatever, apparently should begin with priority “1”. We lose that when deleting the ResetCDR line that was previously above it and as such need to modify the ‘n’ in the the remaining NoCDR line to a 1

Hope this helps someone else save the time it took me to figure it out.


Just as a comment, I think that to some degree ResetCDR and NoCDR may be broken in current versions of Asterisk. See this thread, especially the last few comments…

However I can confirm that adding the code in extensions_override_freepbx.conf from dpengelley’s December 1 post has eliminated the double CDR entries on my box.

Edit: Unfortunately, it also means there will be no entry at all for an unanswered call…

This problem only started appearing when * 1.6 came out (1.4 was suppsoed to ahve a stable locked down set). Based on the past history of the asterisk development team changes like this can happen on a whim and sometimes not making them backwards compatible with the previous sub-release. With the whole 1.6 they changed what and how new things are done so it is now possible that how a command operates from one release to the next might not be the same, making it fun to keep up with. The n to throw a big wrench into the mess some of those code changes have been back ported to the latest 1.4 branch and thus messing with a command that for years has worked correctly and suddenly does not.

Otherwise all of those users who have only been upgrading FreePBX and not asterisk would also be complaining.

I was searching around for a different reporting questions and this thread caught my eye because I’ve been perplexed with the dual entries in my CDR database.

Have there been any updates on this? I’m dealing with the dual entries for the moment, but it sure would be nice to be able to clean my database up and know it will stay that way going forward. I haven’t done the above override because I do need to see incomplete calls in our company.

So have there been any new findings on this?

There are over 2000 systems running FreePBX 2.9 beta, and we are confident that it is a stable release. But, it is still in beta, and if you are running a production system, well, you might want to wait until at least RC is out.

It also depends on the size of the production system and how complex it is. And as always, do a full backup before upgrading.

Hi Mikael:

Thanks for the reply to my post. I eventually re-installed the PIAF iso and haven’t upgraded FreePBX to 2.9 yet. I am learning more and more everyday :slight_smile: I’ve set up some non-google services to use as backups. Do you think 2.9 is safe for production use yet?

ecase, check your /etc/asterisk/logger_logfiles_additional.conf and /etc/asterisk/logger_logfiles_custom.conf

Make sure that only one has the following line:

If this entry are in both files, you will get duplicate log entries. Remove the line for the _custom file.