[asterisk-bugs] [Asterisk 0012368]: CDR written with incorrect uniqueid

[noreply at bugs.digium.com]

The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=12368 
====================================================================== 
Reported By:                bcnit
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   12368
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             04-04-2008 10:54 CDT
Last Modified:              05-26-2008 18:21 CDT
====================================================================== 
Summary:                    CDR written with incorrect uniqueid
Description: 
Under certain circumstances, I am experiencing multiple CDRs with the same
unique ID. This is 100% reproducible.

The situation is this:

SIP device A calls SIP device B, B puts A on hold and on a second line,
dials C. B speaks to C and then transfers C to A by pressing the 'transfer'
button on the phone (or hanging the handset up which performs a transfer
automatically).

The unique ID which is duplicated is the one allocated to the original A
to B call (it is duplicated onto the B to C call).

Dialplan debugging shows that when the call from B to C is made it is
allocated a genuinely unique unique ID, but when this CDR comes to be
written out, the unique ID is empty and is replaced with the unique ID of
the original call (i.e. the first call from A to B).

If CDR logging to MySQL is configured as documented on the voip-info wiki
(with the uniqueID field being the primary key), Asterisk can't write the
duplicate record out to the database.

====================================================================== 

---------------------------------------------------------------------- 
 murf - 05-26-08 18:21  
---------------------------------------------------------------------- 
I've sat on this issue for a while to see if there's any community input on
the issue, and have today decided to close it with "won't fix". 

Why? because there is little I can do about it. The channel is assigned a
new "uniqueid" when it is created, and keeps it until it is destroyed. This
rule is, as far as I can tell, never broken. If that same channel is
involved in several call legs (via xfers, etc.), then it would be foolish
to try to set it to something different. You can surely wager that there
are users now depending on this behavior in CDR applications. I promised I
won't pull the rug out from under users in this way, and I will keep my
promise in this case.

I think what you are looking for, is more of a call-leg unique number,
which is most likely the row # in the database. In the newcdr branch (look
for the CEL enhancement request in bugs.digium.com
(http://bugs.digium.com/view.php?id=110099), we have just
added the "linkedid" field, which will tie call-legs together in xfer
situations. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-26-08 18:21  murf           Note Added: 0087318                          
======================================================================