[asterisk-bugs] [Asterisk 0017334]: [regression] CDRs being written where they were not before after revision 258670

Asterisk Bug Tracker noreply at bugs.digium.com
Wed May 19 12:13:07 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17334 
====================================================================== 
Reported By:                jvandal
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   17334
Category:                   CDR/General
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
Target Version:             1.4.32
Asterisk Version:           1.4.32-rc1 
JIRA:                       SWP-1458 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 262898 
Request Review:              
====================================================================== 
Date Submitted:             2010-05-13 11:26 CDT
Last Modified:              2010-05-19 12:13 CDT
====================================================================== 
Summary:                    [regression] CDRs being written where they were not
before after revision 258670
Description: 
The following changes on 1.4 SVN cause lots of problems ...

By sample, I dial a Queue (ACD) and hangup ... I have an ABANDON event on
Queue Log but no CDR records.

If I enable 'unanswered=yes' on cdr.conf, now I have CDR ...

------------------------------------------------------------------------
r258670 | mnicholson | 2010-04-22 17:49:07 -0400 (Thu, 22 Apr 2010) | 11
lines

Fix broken CDR behavior.

This change allows a CDR record previously marked with disposition
ANSWERED to be set as BUSY or NO ANSWER.

Additionally this change partially reverts r235635 and does not set the
AST_CDR_FLAG_ORIGINATED flag on CDRs
generated from ast_call().  To preserve proper CDR behavior, the
AST_CDR_FLAG_DIALED flag is now cleared from
all brige CDRs in ast_bridge_call().

(closes issue https://issues.asterisk.org/view.php?id=16797)
Reported by: VarnishedOtter
Tested by: mnicholson


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016797 Originating a call from within the dial...
====================================================================== 

---------------------------------------------------------------------- 
 (0122168) mnicholson (administrator) - 2010-05-19 12:13
 https://issues.asterisk.org/view.php?id=17334#c122168 
---------------------------------------------------------------------- 
Part of this change in behavior a result of the change that allows CDRs
previously marked as "ANSWERED" to now be marked as "NO ANSWER" and "BUSY".
 When a call is abandoned in the queue, the CDR record for that channel is
marked "NO ANSWER".  Before r258670, this was ignored and the disposition
incorrectly remained "ANSWERED".

Unfortunately the disposition field in CDRs is not capable of holding all
of the information someone using CDRs might want.  In this case, the
incoming channel is "ANSWERED" but it's attempts to be bridged with an
agent fail, thus causing that part of the call to unanswered.  It is
impossible to store that data in the disposition field and neither
"ANSWERED" or "NO ANSWER" is the complete correct disposition.  Some users
will want to see "ANSWERED"  in that field but others will want to see "NO
ANSWER". 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-19 12:13 mnicholson     Note Added: 0122168                          
======================================================================




More information about the asterisk-bugs mailing list