|Summary:||ASTERISK-12919: Answered calls have no duration on Asterisk 1.4.22|
|Reporter:||Hidalgo Felipe (fhidalgo)||Labels:|
|Date Opened:||2008-10-17 00:24:35||Date Closed:||2011-06-07 14:07:57|
|Description:||Incoming and Outbound Calls has no duration. DtStart,Dtanswer,Dtend have the same valude whem the call in no answered.|
This data is very important because some calls are billed after 6 or 30 seconds no matter if the call is answered or not.
|Comments:||By: Leif Madsen (lmadsen) 2008-10-17 15:06:16|
murf, I'm assigning this to you in the hopes it can be resolved quickly. Is this expected behaviour?
By: Steve Murphy (murf) 2008-10-24 15:44:04
I need to know which backend you are using, for instance pgsql, cdr_csv, cdr_custom, cdr_odbc, etc.
I also need to know which kind of phone technology the calls are being to/from.
Are they SIP phones, or IAX, or Dahdi?
I also need to know exactly the sequence of events you go thru to get this behavior. So me an example CDR that si bad. If it's simply call a number,
extension B answers, they talk, they both hang up, then it should be pretty easy to fix. If it involves a transfer, well, not so easy.
By: Hidalgo Felipe (fhidalgo) 2008-10-24 19:00:32
I found that the problem was reported as "(0013251) endbeforehexten=yes is useless now"
I use the exten H for creating a MYSQL Database for billing, this database has the CDR fields plus additional fields like, LATA, City, State where the call was originated o finalized, the DID for incoming calls and the rate charged to the call.
In * 1.4.22 the functionality of exten H was changed and the parameter of cdr.conf endbeforehexten=yes has no effect.
I has 17 * installations in production and this is a critical paramter for us.
One of the main reasons for us to migrate to 1.4.22 is because CHANSPY produce * crash when the SPYGROUP is emptied. I understand the ChanSpy problem was solved on 1.4.22
The CDR CSV (Master.csv) is correct and has all the information regardinbg call duration and Date/Time.
By: Steve Murphy (murf) 2008-10-24 20:18:04
Hmmm. The endbeforehexten prob was solved in rev 146126 and 150637, and I'm working on another crash that occurs when 'early hangups' occur during parking.
See bug 13640, the patch is ready for testing and attached there).
If you don't do a lot of parking, then 1.4 svn should clear up your problems, and allow endbeforehexten to operate as it had previously. If you could approve the patch on 13640, I could get it committed, and make the fixes even more solid.
By: Steve Murphy (murf) 2009-02-26 12:36:38.000-0600
Since feedback was requested back in October, and no response since then, I'm going to close this bug. I'm going to assume that the endbeforehexten fix that was merged earlier has indeed solved the problem.
If the reporter is still having problems, he is welcome to reopen the bug and present new evidence.