When a CDR is forked, a new CDR is created and appended to the CDR chain for
the Party A. The forked CDR starts life off as a clone of the last
non-finalized for the particular Party A. In the past, merely copying over
the snapshots for Party A/Party B would be sufficient. However, as the CDRs
now contain cached information from Party A - specifically application/data,
context, and extension - we need to copy that over during a fork as well.
Huzzah for unit tests catching this when the context/extension were derived
from a cached value on the CDR instead of on Party A.
........
Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422770 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422771
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
}
new_cdr->fn_table = cdr_obj->fn_table;
ast_string_field_set(new_cdr, bridge, cdr->bridge);
+ ast_string_field_set(new_cdr, appl, cdr->appl);
+ ast_string_field_set(new_cdr, data, cdr->data);
+ ast_string_field_set(new_cdr, context, cdr->context);
+ ast_string_field_set(new_cdr, exten, cdr->exten);
new_cdr->flags = cdr->flags;
/* Explicitly clear the AST_CDR_LOCK_APP flag - we want
* the application to be changed on the new CDR if the