[asterisk-bugs] [Asterisk 0017762]: CDR user fields not updated and CDR() returns invalid data when using Queue with "c" flag

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Aug 5 14:25:51 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17762 
====================================================================== 
Reported By:                kkm
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17762
Category:                   CDR/General
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.10 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-29 19:52 CDT
Last Modified:              2010-08-05 14:25 CDT
====================================================================== 
Summary:                    CDR user fields not updated and CDR() returns
invalid data when using Queue with "c" flag
Description: 
When Queue() is called with the "c" flag (continue dialplan after agent
hangup):
1. assignments made to CDR(...) values from the h extension are not
written to the database; these are the userfield and all additional custom
fields (used with  adaptive_odbc).
2. CDR() fields are reset to defaults. These are CDR(billsec),
CDR(duration), CDR(disposition) -- possibly more.
====================================================================== 

---------------------------------------------------------------------- 
 (0125587) lmadsen (administrator) - 2010-08-05 14:25
 https://issues.asterisk.org/view.php?id=17762#c125587 
---------------------------------------------------------------------- 
I asked Tilghman on IRC about this issue, and here is some of the
discussion and his thoughts. It seems you're going to be better off with
CEL in Asterisk 1.8 than us modifying the CDRs again here, because when we
knock one gopher down another pops up, especially in edge cases like this.


<Corydon76-dig> Oh, I know what it is

<Corydon76-dig> Murf changed how CDRs are generated, and in that case,
he's looking at the bridge CDR

<Corydon76-dig> There should be an additional CDR after the bridge, but
because it's reset, there isn't

<Corydon76-dig> although I'm confused why the "h" extension values aren't
getting set, because the bridge explicitly calls the "h" extension at the
conclusion of the bridge

<Corydon76-dig> probably what he means is that the "h" extension isn't
getting called AGAIN after the dialplan continues

<leifmadsen> hmm, ya that makes sense

<leifmadsen> I guess he's expecting it to be called for the hungup channel
and again after the other channel hangs up?

<Corydon76-dig> How to resolve this, though, is going to be a major PITA. 
Best way would probably be to redirect him to CEL

<Corydon76-dig> Well, the CDR is only ever posted from the controlling
channel

<Corydon76-dig> except in the case of a bridge, in which case, it's called
from the bridge code

<Corydon76-dig> It's even further complicated by this being a Queue

<Corydon76-dig> what was fun is that we put in a ton of effort into making
sure that the "h" extension will never run a second time for a single call

<Corydon76-dig> so once it's called for the bridge, see ya, so long, no
more... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-05 14:25 lmadsen        Note Added: 0125587                          
======================================================================




More information about the asterisk-bugs mailing list