[asterisk-bugs] [Asterisk 0015180]: [patch] No unique identifier for CDR

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15180 
====================================================================== 
Reported By:                Nick_Lewis
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   15180
Category:                   CDR/General
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-22 08:45 CDT
Last Modified:              2009-10-27 09:32 CDT
====================================================================== 
Summary:                    [patch] No unique identifier for CDR
Description: 
There is no unique identifier for a CDR. This makes it difficult to
associate other things such as call monitor recordings with a CDR. 
Each call does have a unique identifier which is stored in the CDR as
"uniqueid" but there may be multiple CDRs representing one call. For
example ResetCDR(w) saves a CDR and creates a new one for the call. Both
CDR have the same "uniqueid".
====================================================================== 

---------------------------------------------------------------------- 
 (0112811) Nick_Lewis (reporter) - 2009-10-27 09:32
 https://issues.asterisk.org/view.php?id=15180#c112811 
---------------------------------------------------------------------- 
Sorry I had forgotten about forkcdr

Rather than using the channel based "uniqueid" which can be swapped out
during a source end transfer, why not use the recently introduced
"linkedid" as the basis for the "sequence". This linked id reliably follows
the call so does not suffer from the same problems. (originally suggested
by Atis Lezdins)

I guess the current cdr->linkedid variable would need to become a pointer
to a new linkedid structure containing the old linkedid variable and a
sequence variable. Then 

linkedid = cdr->linkedid;
cdr->sequence = ast_atomic_fetchadd_int(linkedid->sequence, 1));
 

The "linkedid"/"sequence" combination would work for me (as would uuid) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-27 09:32 Nick_Lewis     Note Added: 0112811                          
======================================================================