Tap here to compare the top VoIP providersTap here to hide the top VoIP Providers
Asterisk cmd ForkCDR
SynopsisForks the Call Data Record
Causes the Call Data Record to fork an additional cdr record starting from the time of the fork call. This new cdr record will be linked to end of the list of cdr records attached to the channel.
The original CDR is has a LOCKED flag set, which forces most cdr operations to skip it, except for the functions that set the answer and end times, which ignore the LOCKED flag. This allows all the cdr records in the channel to be 'ended' together when the channel is closed. The CDR() func (when setting CDR values) normally ignores the LOCKED flag also, but has options to vary its behavior. The 'T' option (described below), can override this behavior, but beware the risks.
Optionsv - When the new CDR is forked, it gets a copy of the vars attached to the current CDR. The vars attached to the original CDR are removed unless this option is specified.
a - If the original cdr record has an answer time set, then the new forked cdr record will have its answer time set to its start time. If the old answer time were carried forward the answer time would be earlier than the start time, giving strange duration and billsec times.
d - The disposition is copied from the original cdr record to the new forked cdr.
D - The destination channel field in the new forked CDR is erased.
e - The 'end' time for the original cdr record is set to the current time. Future hang-up or ending events will not override this time stamp.
A - The original cdr record will have it ANS_LOCKED flag set, which prevent future answer events from updating the original cdr record's disposition
DescriptionFork The CDR into 2 separate entities.
Related issuesTake a look at the "notransfer=yes" (1.2) resp. "transfer=no" (1.4) setting in iax.conf
- ForkCDR() was added YYYY and was part of Asterisk version XXXX
Background info on confusing CDRsThe core of Asterisk is a threading model but a very conservative one. Only origination channels and channels executing an application have threads. The B leg of any call operate only within the same thread as the A leg and when something happens like a call transfer the channel must first be transferred to a threaded mode which often times includes a practice called channel masquerade, a process where all the internals of a channel are torn from one dynamic memory object and placed into another. A practice that was once described in the code comments as being “nasty”.
The same went for the opposite operation the thread was discarded by cloning the channel and letting the original hang-up which also required hacking the cdr structure to avoid seeing it as a new call. One will often see 3 or 4 channels up for a single call during a call transfer because of this. For Asterisk 1.6 (or later) we might see a completely re-designed method to generate and store CDR data; see bug 11093
- Asterisk cmd NoCDR
- Asterisk cmd ResetCDR
- cdr_shell - 3rd party solution that executes a script with the cdr data in its argv 0-18
- Asterisk billing: More information on CDR and billing in Asterisk
Asterisk | Applications | Functions | Variables | Expressions | Asterisk FAQ
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+