Asterisk 1.6.2, CDR & MySQL -> missing records

Hi,
I’m using Asterisk 1.6.2.13 in an elastix enviroment, with a DAHDI card. I use the CDR to calculate billings etc, so I’ve configured asterisk for writing it directly in to mysql with cdr_mysql.conf.
The database is in the same machine and so the connection between asterisk and mysql is via socket, the table engine is InnoDB.
When a call come into asterisk it’s passed to a queue, I want to use the CDR data to read the “history” of the call but I’m experiencing a weird problem: sometimes the CDR is showing all records for a call, sometimes no.
Here’s an example of a correct CDR sequence, only relevant fields (sorry for the line breaks…):

+---------------------+-------------------+------------------------------+------------------------------+---------------------------+-------------+
| calldate            | uniqueid          | channel                      | dstchannel                   | lastdata                  | disposition |
+---------------------+-------------------+------------------------------+------------------------------+---------------------------+-------------+
| 2011-11-14 12:42:29 | 1321281749.418241 | DAHDI/1-1                    | Local/1006@from-queue-32ee;1 | 01,t,,                    | ANSWERED    | 
| 2011-11-14 12:42:30 | 1321281750.418247 | Local/1001@from-queue-2ed2;2 | SIP/1001-0000705b            | 20                        | BUSY        | 
| 2011-11-14 12:42:34 | 1321281754.418250 | Local/1005@from-queue-afcf;2 | SIP/1005-0000705c            | 20                        | BUSY        | 
| 2011-11-14 12:42:36 | 1321281756.418255 | Local/1006@from-queue-32ee;2 | SIP/1006-0000705d            | SIP/1006,,trM(auto-blkvm) | ANSWERED    | 
+---------------------+-------------------+------------------------------+------------------------------+---------------------------+-------------+

you can see four records, the first for the incoming call with the destination channel, and the last for the answer.
Here’s an example of an incorrect CDR:

+---------------------+-------------------+------------------------------+------------------------------+---------------------------+-------------+ | calldate | uniqueid | channel | dstchannel | lastdata | disposition | +---------------------+-------------------+------------------------------+------------------------------+---------------------------+-------------+ | 2011-12-30 12:29:00 | 1325255340.670190 | Local/1004@from-queue-23d5;2 | SIP/1004-00007d57 | 20 | BUSY | | 2011-12-30 12:29:16 | 1325255356.670232 | Local/1005@from-queue-39c0;2 | SIP/1005-00007d5c | 20 | BUSY | | 2011-12-30 12:33:39 | 1325255619.670639 | Local/1006@from-queue-f8b0;2 | SIP/1006-00007d79 | SIP/1006,,trM(auto-blkvm) | NO ANSWER | +---------------------+-------------------+------------------------------+------------------------------+---------------------------+-------------+ [/size]

you can see that the first record is missing, there’s no DAHDI record and so I cannot know when the call entered and I have no idea how to identify the call.

Have anyone experienced problems like that?

Thank you.

bump! no ideas? :smile:

wow, owned!