CDR shows an entry for every extension

(12.7.3-1708-1.sng7)

After a recent migration to a V14 system, I see that every incoming call is listed for every ringing extension.

20 extions, 20 CDR lines for every call. 19 show No Answer and the extension that answers shows Answered.

Is this normal? How do I stop this happening?

I see no real benefit in this, especially as the Destination on all of them shows the Ring group number and not the extension.

Hi Les:

Yes this is normal, no you can’t stop them from being logged. You can set a filter to show only Answered calls, or show calls that are not “No Answer” with:
image

You can get additional information by holding the mouse pointer over the destination, which shows the extension.

Thanks Lorne. At least I’m not doing anything wrong!

On the old system I had one entry per incoming call - whether answered or not.

If I set Disposition to No Answer I get hundreds of entries which are not really of any use. I just want to see one entry per unanswered call. Currently you can’t see the wood for the trees.

I suppose I can live with it, but from a design point of view I find it rather rather lacking in usability.

You probably came from asterisk 11. In asterisk 12 Digium changed how local channels worked and thus how they were logged into the cdr

1 Like

Correct. I suppose this is called progress.:frowning_face:

Personally this is not a major problem for me, but with my system designer hat on, it seems that a simple option in the CDR module would turn it into a much more usable display.

I have not looked at the internal workings, but it looks like that the records could optionally be grouped on all of the visible fields and thus end up with just a few lines - one for each Disposition.

I can’t think of a simple option to make this better

We’ve talked about this before, and one of the suggestions that comes up is to identify which of the records you want to keep and discard the rest. Unfortunately, everyone has a different idea of which records are meaningful and which aren’t.

The advantage of this approach is that every call (to and from Asterisk) is tracked now, where before they weren’t. This should make some classes of troubleshooting easier, since now there’s data where they wasn’t before.

Points taken.

My use of the CDR report is to quickly see missed calls and to sometimes check how long I have spent on a particular call for the purpose of client charging.

So I only need a limited number of columns. Those that are showing on the screen are fine. For this purpose I do not need the mouse-over fields which show things like the actual channel/extension.

I just ran a ‘group’ query of those columns and got exactly what I wanted.

So a simplified version of that module would be just fine for me. I would tend to agree that it could be messy to try and combine the two types in a single module, as some columns (those unique to each record) would be missing from the query.

All of the CEL and CDR data is stored in a MySQL table in the ‘asteriskcdrdb’ database. Usually, this database is only accessible from the “localhost”, but it is straight MySQL (MariaDB) so using the datastore as a custom source for very specific reports is as simple as writing a report from any other database application.

One of the “when I get some time” ideas I’ve had in the past is to write a general-purpose report generator that allows people to access the database through a cron-job or from a “reports” GUI. At my age, that list of things is already too long to accomplish, but I can still think about how I’d pull general purpose (user-defined) reports.

Of course, you could also hire almost any 13-year-old - I swear these kids these days. When I was starting we had to pound stones together to make our own silicone…

There are also plenty of “hired gun” lists out there where you can find someone that wants to make $50 the hard way…

Even Sangoma could help you out (for a fee) and write you as specific a report as you are willing to fund. CDR/CEL reports are just too personal for the system’s single report to be able to do the specifics of what every organization needs.

Moral: while the reports you have may not do precisely what you need, the solution is only a check-book away.

I went to have a peek at the cdr module code and noticed there a ucp folder which prompted me to look at the ucp widgets and there is a call history one there.

I think that is really what I need.

It shows missed calls even when I am on the phone (I presume due to caller waiting being turned on).

So I concede that changing the cdr is not viable and I’m happy to leave the cdr for technical troubleshooting.

Thanks for all the feedback.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.