We’re a Fonality customer and have an Asterisk PBX setup with them. We need to make call and queue stats available to a client via a web interface and have written our own interface.
However, when we compare the Master.csv data to Fonality’s reports, we find that Master.csv is missing many outgoing calls that Fonality is logging. Fonality swears that their script is reading the same logs ours are, but I don’t see where their calls are coming from. The queue_log doesn’t store outbound call information.
To give you an idea, the Master.csv file contains about 30 outbound calls for April while Fonality reports about 530. Most of the missing outbound calls are from extension 7204, but that extension is represented in some of the Master.csv entries… so it’s hit or miss.
Is there an asterisk config option that would cause some outbound calls to be logged but not others?
We make about 530 outgoing calls/mo according to fonality’s reports. However, when parsing through the master.csv.* cdr log files for that month, only about 30 outgoing calls appear. There does not appear to be any pattern to the missing calls – some extensions have calls logged some times and not others.
The question is… where are those calls logged if not in master.csv, or why wouldn’t they be logged in master.csv?
I definitely am not looking at the data wrong in the Master.csv file(s) (rotated every 5 minutes). I did a text string search over an entire week of master.csv.* files on an extension by extension basis. The only way the outgoing calls could be in there is if they aren’t given the same “callerid” as fonality reports.
As for the other two… I’m a web programmer assigned to parse the CSV data and am unfamiliar with asterisk setup… which is why I’m here. I’ll dig into your suggestions.
By the way, 7204 gets the bulk of the calls that fonality is reporting, and most of the missing calls are assigned to 7204. However, there are a few 7204 outgoing calls logged in the master.csv.* files.
How are the logs being rotated? Is is possible the rotation script is allowing cdr’s to be missed? 5 Minutes is extremely short especially for a server doing 500 or so external calls a month.
In addition to forwarding, check and see if the person at that extension transfers calls out as well.
You may also want to go through the log files manually to reconcile each record to see what may be happening. (Maybe the extension number is not in the record for some reason therefore not being picked up by your text search)
The server does 500 outgoing calls/mo, but it handles approximately 150,000 incoming calls/mo. The incoming calls match up nearly perfectly (one or two calls/mo are listed in the master.csv.* files that don’t make it into fonality’s reports) while we are way off on the outgoing calls.
Because of that difference, I’m inclined to doubt the rotation has anything to do with this.
I have gone through the master.csv.* files manually looking for a few of the missing calls. The data simply isn’t there.
Couple of things, rotating every 5 mins will/may cause problems. if you want to do this why not write to 2 files. simplist way would be for ALL extensions have the same accountcode varible assigned to them this way you will create a file of all outgoing calls.
Also look to impliment mysql cdr storage and then you can get your data direct from the database.
Sorry, I was in error… the logs rotate approximately every 15 minutes.
Fonality configured a large portion of the server, including the log rotation. I have to defer to them. But I would be very surprised if the log rotation is causing the problem, considering that we have so many more incoming calls, and they are almost 100% perfect.
I have been hoping that the problem is a configuration issue that wouldn’t require recompiling asterisk, as the mysql cdr-csv config requires. Also, we are using asterisk 1.2.17 (again, I don’t know why that version).
I decided to try some new searches with the data from fonality that is missing in the master.csv files.
What I found is that the calls ARE all there. However, if an extension dials 9 before calling out, then it stores the PBX phone number in the log instead of the extension that calls out. We need to be able to store the extension for all outgoing calls.
How can we solve this? If disabling dialing 9 is our only option, how can we do that?
I have uncovered a bit more detail.
Until noon on April 1, all calls using 9 to dial out were logged to their extension. After 1:30pm on April 1 until the present, all calls using 9 to dial out were logged to the PBX number, not the extension.
I have no idea what Asterisk setting chooses this, but something must have changed on that day. I’ve notified the IT guy who has been working with the PBX.
It would be nice if anyone could offer any ideas so we can resolve this. Thanks.
Thanks for the advice. Apparently, this was something fonality changed on that date. Perhaps they will give us something helpful to resolve it.
We need the originating extension because our extensions are organized into groups based on the first two numbers of the extension, and we do stats on those groups that match up with different queues. Matching to the channel is a problem because we’d have to maintain a separate table just to match up the MAC address of a given phone to the queue group. Managing that would be rather painful, and a phone could never be assigned to a different queue group, or else the data would never be 100% accurate.
It should be hard to parse the files using column 6 as for example if all the extensions are sip then you ignore SIP/ and then read the next X digits as your extension
why ?
The actual Fields are
accountcode: What account number to use: account, (string, 20 characters)
dstchannel: Destination channel if appropriate (80 characters)
lastapp: Last application if appropriate (80 characters)
lastdata: Last application data (arguments) (80 characters)
start: Start of call (date/time)
answer: Anwer of call (date/time)
end: End of call (date/time)
duration: Total time in system, in seconds (integer), from dial to hangup
billsec: Total time call is up, in seconds (integer), from answer to hangup
disposition: What happened to the call: ANSWERED, NO ANSWER, BUSY, FAILED (on some CDR backends, e.g. ODBC, these may be integers; note that more detailed info can be found in the dialplan variable $HANGUPCAUSE)
amaflags: What flags to use: see amaflags: DOCUMENTATION, BILLING, IGNORE etc, specified on a per channel basis like accountcode.
user field: A user-defined field, maximum 255 characters [/quote]
You could also do like ianplain suggested above and specify the account code on the sip peer level. Set the code as the group the phone belongs to. Then you’d have 1 file per group with all of the associated records for outbound.
Here’s an example field 6:
SIP/0004F2035277-b3b56270
My PBX guy says that 0004F2035277 is the mac address for the phone, but he doesn’t know what the string after the dash is. I did some searching, and it seems that string is almost always different from entry to entry. In cases where that part is the same, it is a different phone and a different extension making the call – I don’t see any pattern to it.
Also, there are outgoing calls with a field 6 similar to the following:
Local/91xxxxxxxxxx@internal-ee71,2
(where x’s represent the outgoing phone number digits)
I am uncertain as to the case where a call uses the local channel vs. SIP, but we have to account for these calls as well.
That’s why we were sticking to the extension in the log. If the channel log entry could be configured to match Ian’s and/or Dave’s descriptions, that would obviously be useful.