From Yate Documentation
The call.cdr message seems to be emitted by a CDR building module (such as cdrbuild) towards a CDR logging modules (such as cdrfile).
The message seems to have been designed for asynchronous processing (broadcast).
- one of initialize, update or finalize depending on the state of the CDR being signalled out
- UNIX time and date when the CDR has been initially generated (i.e. an update following an initialize will bear the time of the original initialize even though it may well be emitted later on)
- module and module-specific channel name being involved in this CDR
- module-specific channel endpoint address being involved in this CDR
- either of incoming or outgoing, Yate instance-wise (i.e. a call coming into the Yate instance emitting this CDR will have incoming here and a call being generated from the Yate instance in question will have outgoing here)
- will hold the billing ID
- module-specific caller party ID
- module-specific called party ID
- end-to-end time (in seconds) of the call described in this CDR (i.e. from the moment the last digit was dialed on the calling side until the moment the line was hung up)
- effective payable time (in seconds) of the call described in this CDR (i.e. from the moment the line was picked up on the called side until the moment the line was hung up)
- ringing time (in seconds) of the call described in this CDR (i.e. from the moment the routing decision has been taken and the remote endpoint alerted of the incoming call until the moment the line was picked up on the called side)
- one of incoming, outgoing, ringing, answered or connected, reflecting the current state of the call referred to by this CDR
- a (mostly) human readable reason for this CDR.