Hi,
One the frequently request on FreePBX and Asterisk is a good reporting tool. Asterisk CDR is not accurate. So I want to know there is any solution for this requirement?
I know that there is a commercial module for this too. But I want to know this is perfect and is accurate in reporting?
PS: in all of years, Asterisk CDR is changed?
Regards.
Ineed my 11 years I have heard many complaints about asterisk but I have never heard a complainthat about the accuracy of cdr reports.
What specifically is inaccurate
Sometimes the records not inserted in CDR. Please consider Asterisk CDR is ok, what is the best solution for reporting on FreePBX and Asterisk?
Please identify a call that was not inserted.
So you mean there are some reason to this happens? and try to find them?
No, there is no feasible reason that freepbx doesn’t generate the cdr records, you will need to support your contention that it does not do so.
… and if that is a problem, you should be setting up two CDR sinks. I use a CSV file directory in /usr/spool/asterisk/cdr-csv/ and MySQL for CDR. If I miss one, I hit the other.
Is this a “belt and suspenders” approach to be safe, or are you aware of cases where calls do not get logged in the CD-R?
Belt and Suspenders - my database server is on another server (common to a group of PBX servers) so, if there’s ever a problem, I still get all of my CDR information in the CSV directory (which I then insert into the database at the end of the day).
You can set up as many cdr backends as you want, they are generally buffered if “Off net” .
The OP stated that some calls were missing. This is the crux of this thread. So if it is missing in ANY back-end then the problem is elsewhere, and probably not FreePBX.
We run a mail order call center on FreePBX, and even with the paid reporting module, have always found the reporting to be mostly useless. Even simple things like getting the total number of calls into a particular DID are impossible.
We actually hand logged the calls (on paper) for two separate days to verify the reports. Our hand written logs didn’t even come close the totals reported by FreePBX. In some cases, the reports showed 2 1/2 times the actual number of calls.
In the end, we set up MySQL to allow connections from two PCs on our network, and we wrote some code to generate our own reports. They now report realistic call statistics.
Over all, we are very happy with FreePBX and the great support from Sangoma. The only real disappointment has been with call reporting. We had a Mitel system before moving to FreePBX, and really do appreciate the flexibility and freedom we have with an open project like FreePBX. The one thing that Mitel really had figured out however, was reporting for call centers. The only negative feedback we got from management/ownership after the migration to FreePBX was call reporting. The comments from management were along the lines of “they really don’t understand call center reporting, do they?”
That’s why we had to build an internal solution. I wish I were a better PHP/Web developer, I would like to be able to contribute back to the project. Our solution is very specific to our needs, and I also would swear that there is duck-tape involved somewhere!
Bruce
I have never used the solution before however I have seen it here referenced over the years, but would A2Billing help here at all??
I agree that the CDR reports are difficult to read if not almost useless sometimes. We made some changes yesterday so I wanted to look at the CDR if anything jumps out i.e. disconnected calls, lower volume, etc…
I search for 11/19 and get "Call Detail Record - Search Returned 100 Calls"
but on closer inspection it’s NOT 100 calls. The screen is full of CEL events for the same call.
The data below is 1 single call. How is this usefull?
I am not saying CEL is not useful. It is. Clicking on 1479593049.795 opens the CEL window which is quite informative. It’s just very confusing in the CDR report to have 10 lines for one single call.
2016-11-19 17:05:26 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:05
2016-11-19 17:05:21 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:04
2016-11-19 17:05:20 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:05:18 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
2016-11-19 17:05:14 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:03
2016-11-19 17:05:11 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
2016-11-19 17:05:09 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:05:05 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:04
2016-11-19 17:05:03 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:05:01 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:04:59 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
2016-11-19 17:04:56 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
@dcitelecom looks like something is broken on your box…
I get only one entry per call in the CDR report…
Have a nice day!
Nick
I am using the lastest Distro and nothing is really broken but you are partially right. Thanks for making me look.
I am feeding the call into a2billing and the user was dialing an invalid number string which made a2billing try different trunks. Each time it tried a new trunk it generates a new CDR record and there seems to be a bug in that a2billing doesn’t stop after the 2 defined failovers but continues looping from trunk A -> B -> C -> A -> B -> C etc… (It’s supposed to stop at C)
Each time it does that a CDR record is generated which is wrong. In my case it’s a bit extreme and I will fix it but the CDR module should know it’s the same call and generate only 1 single record with the trunk failover mess showing in the CEL.
I could be wrong but I always thought it was Asterisk itself that was writing in the CDR table and not the CDR module which only queries that table…
If so, the multiple entries you see (caused by a2billing) are actually in the table and I guess the best the CDR report could do is offer a way to remove duplicate System UniqueID.
Should it do that by default, I am not so sure… For someone like me which doesn’t use a2billing I would like to know if there were such a weird thing going on my system…
I think your best bet would be to contact the a2billing people to see if there is anything that can be done on that side and if not maybe you could do a feature request to the FreePBX people to have a checkbox that remove duplicate System UniqueID…
Have a nice day!
Nick
I think our problems with multiple entries for a single call centered around how the calls were handled in the queues. Sometimes our call center staff will get presented with a call, but are busy with something like web chat for example, and let the call “roll over” to the next agent. Each time the call goes back to the queue, ti generates another CDR record.
The paid queue reporting module doesn’t know how to handle this either. We have always had inaccurate data in the reports.
Hi!
Do they have identical System UniqueID?
Have a nice day!
Nick
Why would a call go back into queue. Are you saying you are failing over a timeout back to the queue? If so then that is a new call into the queue and not sure why would would do that. Just set your wait time to be higher.
In our case (with a2billing) it’s the same identical System UniqueID.
It’s caused by a2billing going back to the dialtone after a failed call attempt and the user can enter the destination number again. That seems to be considered a new call but with the same identical System UniqueID.
In my opinion the CDR module should not print duplicate entries (no matter the reason) as there are a million ways to use FreePBX. I am not a programmer but the CDR query could filter for unique System ID when generating the report.