FreePBX | Register | Issues | Wiki | Portal | Support

CDR reports have duplicate entries


#1

FreePBX 14.0.1.20

New install/upgrade. The CDR reports are crazy. There are duplicate identical entries for every extension in a ring group for each incoming call.
I see that one can click on the link in the “System” column field and see more detail, but that is where the duplicate entries should be broke out. One CDR entry for each incoming call, click on the link to see the detail of duplicate entries and the call event log.
Having to scroll through 25 or more entries for each incoming call, need I repeat, duplicate entries, is out of control. In what scenario would this be useful?

Is there an option (check box, config entry) for this?


(Dave Burgess) #2

That’s by design - they aren’t identical, there is one for each extension in the group, which makes sense if you think about it. Remember, this isn’t a telephone switch, it’s a back to back user agent, so each of the connections from the server to the extensions is a new call.


#3

There is nothing to differentiate one extension call from another. For each incoming call entry the timestamp is the same, system “unique” id is the same, the caller id is the same… Everything in the entry is identical with nothing showing a unique call to an extension. One call, twenty five identical entries.
I have used CDR logs for many reasons in the past as a record of incoming and outgoing calls, but now I will have hundreds of pages with duplicate links for every incoming call to wade through.

With all due respect I have thought of it and it does not make sense.


#4

I don’t need an entry for every call to a phone in a ring group as the Destination column shows the ring group that is receiving the call. That detail you refer to should be moved behind the system “unique” id link.


(Andrew Nagy) #5

Sorry this is how it works.


(Dave Burgess) #6

… and it’s not a FreePBX thing. This is an Asterisk affect. It’s one of the most common complaints about CDR, but the counter argument (that every call from or to the system needs to be logged) wins. As with most database applications, if you are unhappy with the source data, you can filter the data the way you want it filtered.


#7

So what you are saying… the snippet above representing a subset of dozens of redundant entries with nothing to indicate an individual identity is by design?
And you are seriously content with that?


#8

Even better. The above image is from clicking on the call log detail from the blacklist.
One call, nine entries. All for the same one incoming call.

This actually indicates a different issue as the call came in at 3:04pm not 20:04.
In fact all blacklist call log detail screens are 5 hours off from the incoming call time.


(Dave Burgess) #9

If you don’t like it, find a better system or fix it. Asterisk is still open source. Don’t just stand around and bitch at us - take some responsibility and give back.

I didn’t write it, I just use it. I’ve already told you twice that it neither a FreePBX thing and that it’s the most common complaint about the system. It’s the primary reason why CEL is becoming the new call data source.


#10

The original post was seeking a solution to this problem.

To Mr. Burgess:
I would love to fix it if I knew where to look. (See original post)
Since you did not write it and you have no solution for this issue, perhaps you could refrain from posting replies to this forum post. I hear Twitter and Reddit are good places to opine.


(Dave Burgess) #11

I do have a solution for you. Just because you think the system doesn’t work right doesn’t mean it’s wrong. The system has been working like this since well before you joined this forum and is certainly not news. The semantics for the CDR table was publically announced with the upgrade to version 11 (IIRC) because people complained that Asterisk wasn’t reporting all of the calls in the system. The assumption (once again, as I recall) was that having too much pertinent data was better than not having data someone might need.

I did, in fact, explain (not opine) to you why the system does it and offered you the solution. Here’s another one: submit an Issues ticket and ask for the “duplicates” to be removed from the report. Note that you may be directed to the Call Event Logging table for relief, but apparently, you believe that your perspective is the only one possible (that last part is an opinion).

@tm1000 explained it to you and so did I, but somehow you’ve decided that we’re wrong?

If you want the “report” fixed, you can certainly do that. The source code for the basic reports module is open source. Fix it and submit a patch.

So, to recap the possible solutions:

  • You can submit an Issues Ticket for support to get a checkbox added to the reports module. Note that without a ticket, no change to the system is likely.
  • You can update the software to do what you want it to do and submit patches through the same Issues interface.
  • You can change your source for call information and start using CEL instead of CDR, Note that this may also require an Issues ticket if you aren’t a programmer.
  • You can accept the fact that Asterisk produces these entries for a reason and adjust your expectations.

So there you go - four possible solutions. Is there anything else you’d like help with?


#12

https://issues.asterisk.org/jira/plugins/servlet/mobile#issue/ASTERISK-24016


(Lorne Gaetz) #13

IMO this thread is getting needlessly personal, perhaps some deep breaths all around…

I assume you’ve already noticed that you can filter CDR records by disposition where you can display only ANSWERED or perhaps even better filer by NOT NO ANSWER.

There is no way that reporting can be all things to all users, some people need and want detail, many don’t. The fix is not dropping records, it is giving a range of filtering tools to users so they can ignore the ones they don’t want.


#14

To Burgess: I guess it would be impolite to post what I am thinking right now…

Igaetz: Yes, thank you for your reply.

dicko: Thank you for the link.

Burgess: This is my last word on this topic. The link dicko provided was immensely informative. Please take note on how this is done.