FreePBX reports -- 2 calls for 1 real call
Hey all, I am using Trixbox 2.4 CE and having a little reporting problem.
When I am making a call it actually appears in the log as two calls.
For example:
2008-02-08 12:20:17 SIP/8101-b... 8101 "nec1" <8101> 0390182801 NO ANSWER 00:09
2008-02-08 12:20:17 IAX2/mytel... 8101 8101 s NO ANSWER 00:09
It shows that a Sip extention 8101 has made a call to "S" using IAX2/mytel
IAX2/mytel is my outgoing provider.
It then shows another record with the Sip extention NEC1 8101 making a call to 0390182801 using channel SIP/8101.
The calls work perfectly, however in the report I only want to NEC1 8101 to call 0390182801 (even using channel IAX2/mytel would be nice).
Any ideas?
This is not unusual and depending on the path the call takes, including Follow-Me, Ring Groups and other features, you can have 1 record or you can have 10+ records in your call logs and right now that is how it is. It is an area that we (the FreePBX team) are aware of but something that probably won't change for some time to come. It is partially related to the nature of how CDRs are handled in Asterisk and partially related to how we run the dialplan and what we do or don't do to help clean up many of the extra CDR records that get generated.
i am very pleased to have heard this from you, since it has been an annoying issue since 2.4x install. I have not noticed this in 2.2x, however.
It also shows up on the cisco phone call logs as two, three or even four instances - which has had me thinking for a few weeks that there is something wrong....
Now that we know it is not the case, i can scratch that off the lower list of to - do's
Best wishes for a great weekend!
wt
I believe I actually had this problem in version 2.2, but just ticked "DO NOT CHANGE CALLERID" (or something like that) and it fixed the problem. In this version I cannot seem to get rid of it no matter what I try.
It is a straight phone call, no recording, or follow me.... Otherwise I would understand this issue...
Any other ideas?
this has always been a problem all the way back since the issue takes place in asterisk itself. asterisk writes an entry into the CDR for every "call" but its definition of a call is more a technical [and accurate] definition than what a user or business person would define as a call.
for example, if you have a queue with twenty static extensions and a "ringall" strategy selected, then when a call comes in, asterisk will first count the trunk=>queue as a call, the queue then calls all 20 extensions, so asterisk counts 20 more calls [albeit short calls many which will end as "NO ANSWER" or "FAILED"], one of which will get picked up. So, in this example, the CDR will show 2 calls that will show minutes on them that reflect the length of the call plus another 19 that will show a couple of seconds duration ending in "NO ANSWER"/"FAILED".
This means that if you want to use the CDR for useful management information, you have to write your own queries to screen out data that is "technically accurate" but managerially useless.
Unfortunately, this is a non trivial problem to fix because it requires custom queries to really get to the information you are looking to reach.
Good luck to phillipe in how you try to deal with this.
Philippe, I have just returned from reading my freepbx call log reports (had to look up something in december) and discovered that [trixbox v2.2x at that time] you have had only one line entry per call (as opposed to 3-4)
This certainly makes it easier from a reference point of view as it doesnt requrie any manual deciphering.
I would think that most people/business would prefer this if there is a simple way to execute it. I am presuming that in asterisk 1.4, something changed in the way all of this information posts.
I simply put a line that removes all of it from the MYSQL DB....
So periodicly it removes ALL the calls that a non-tech person wouldn't understand....
the line is.
mysql -h hostname -u asteriskuser -pamp109 asteriskcdrdb -e "delete from cdr where dst='s'"
Then it shows only what I really need.


Member Since:
2007-12-21