|Summary:||ASTERISK-13580: CDR not recording in DB even if no error persists|
|Reporter:||Joseph Maiquez (josephm)||Labels:|
|Date Opened:||2009-02-13 21:58:07.000-0600||Date Closed:||2011-06-07 14:03:15|
my cdr works perfectly when I call from sippeers defined in database (extconfig.conf)
but when I got a call from mobile, here is the log
Packet2Packet bridging SIP/XXX.XX.XXX.XXX-08930e50 and SIP/XXXXXX-08937ff8
> cdr_odbc: Query Successful!
== Spawn extension (from-mobile, AGI-SUCCESS, 1) exited non-zero on 'SIP/XXX.XX.XXX.XXX-08930e50'
but when i check in my CDR database, no data is saved
Upon cheking the cdr-csv, there is a record with regards to this call..
If the call from mobile is not answered, the record is successfully saved
Please help.. Its urgent
P.S Im using 1.4.22 i want to know what steps i need to do if in case i need to update to 1.4.23.. what will get affected? is my configurations still remains?
****** ADDITIONAL INFORMATION ******
When i tried to print the ODBC_res i get 1 when not recorded 0 when it successfully recorded in DB
|Comments:||By: Tilghman Lesher (tilghman) 2009-02-14 01:31:41.000-0600|
My recommendation for you is to download the backport of cdr_adaptive_odbc and install it.
svn co http://svncommunity.digium.com/svn/tilghman/branches/1.4
ASTSRC=/path/to/1.4/build/dir make install
Please review the sample config. You will probably have to "alias start => calldate" in order to map the start field into the calldate column.
I'm actually not all that surprised that you have trouble with cdr_odbc. The code is very old and not very fault-tolerant, which is why it has been rewritten in 1.6 and higher.
By: Joseph Maiquez (josephm) 2009-02-15 03:22:30.000-0600
Will it affect the other configurations and the cdr_odbc.conf? What are the changes that will it create to my settings? Please guide me.. Thanks
By: Tilghman Lesher (tilghman) 2009-02-16 10:41:58.000-0600
It will not affect the other configurations, but you should probably unload cdr_odbc.so.
By: Tilghman Lesher (tilghman) 2009-02-19 14:52:02.000-0600
Since there is no further feedback, I am assuming that fixed it. Please report issues of this nature on the asterisk-users mailing list first, in the future.