Resetting the CDR just before DIal used to work, but there have been big changes in CDR and it might no longer work.
As a last resort you can capture the epoch just before Dial and in an answer subroutine.
Note that you can only measure from before DIal to after answer. The actual ringing time could differ. (In some cases, you may get a better estimate of the actual start of ringing by using AMI and detecting the state change.
Hi, thanks for answer my question, can you give me some documents or some topics which related to your answer? Does billsec value in cdr table is the answer?
Billsec is end - answer. You seem to want answer - start. The catch is that, if the outgoing leg start isn’t the same as the incoming leg start and/or the incoming leg is already answered, the default values logged may use the incoming leg start and/or answer times. The only real difference between billsec and answer - start is that there are hidden fractional seconds used in the calculation.
ResetCDR used to both clear the answered state, and reset the start time, but I’m not sure if it still does so.
At one time the preferred solution for non-trivial accounting was to use CEL, but my impression is that so few people took this up that CDR was changed to make it better for most people, but that means my knowledge of how it behaves is out of date.
CEL gives individual events in a call, rather than a summary at the end.
I guess I really ought to ask is what are you using the information for? I’m assuming this is for some sort of after the fact performance analysis. If it is for some more real time purpose, the answer may differ.