And, last but not least, the original cdr record has its LOCKED flag set. Almost all internal CDR functions (except for the funcs that set the end, and answer times, and set a variable) will honor this flag and leave a LOCKED cdr record alone. This means that the newly created forked cdr record will be affected by events transpiring within Asterisk, with the previously noted exceptions.
a- Update the answer time on the NEW CDR just after it's been inited. The new CDR may have been answered already. The reset that forkcdr does will erase the answer time. This will bring it back, but the answer time will be a copy of the fork/start time. It will only do this if the initial cdr was indeed already answered.
A- Lock the original CDR against the answer time being updated. This will allow the disposition on the original CDR to remain the same.
d- Copy the disposition forward from the old cdr, after the init.
D- Clear the
dstchannelon the new CDR after reset.
e- End the original CDR. Do this after all the necessary data is copied from the original CDR to the new forked CDR.
r- Do NOT reset the new cdr.
s(name=val)- Set the CDR var name in the original CDR, with value val.
T- Mark the original CDR with a DONT_TOUCH flag. setvar, answer, and end cdr funcs will obey this flag; normally they don't honor the LOCKED flag set on the original CDR record.
v- 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.
This documentation was imported from Asterisk Version UnknownSVN-branch-1.8-r418641