[asterisk-bugs] [Asterisk 0013691]: Unanswered Queue() calls don't have CDR

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Jan 21 15:48:28 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13691 
====================================================================== 
Reported By:                dferrer
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13691
Category:                   CDR/NewFeature
Reproducibility:            N/A
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 148867 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-14 11:15 CDT
Last Modified:              2009-01-21 15:48 CST
====================================================================== 
Summary:                    Unanswered Queue() calls don't have CDR
Description: 
When a call goes to Queue app without an Answer in its path, and call
doesn't get answered, there is no CDR for this call. The first impression
is that this appears to be a correct behaviour, because I've option
"unanswered=no" in cdr.conf. 
However this 'unanswered' is a bit incoherent, because if I dial B using
Dial app, and B doesn't answer, CDR is posted in this case (field 'channel'
and 'dstchannel' have source and destination channels in this case, so CDR
is posted). For the Queue case, 'dstchannel' is empty, so CDR post is
disabled, as you can see in post_cdr logic to skip unanswered calls.

I'm happy with current behaviour, but I wanted to change it for Queue
calls: I wanted a CDR posted in case of a missed Queue call. I'm attaching
a patch for 1.4.22 and trunk for app_queue for that, I mark CDR as
AST_CDR_FLAG_DONT_TOUCH and in post_cdr it will be "untouched" if cdr is
marked with this flag. Another solution was to put Queue's final
destination channel in 'dstchannel', but this is not elegant when I'm in
'ringall' strategy.

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

---------------------------------------------------------------------- 
 (0098362) murf (administrator) - 2009-01-21 15:48
 http://bugs.digium.com/view.php?id=13691#c98362 
---------------------------------------------------------------------- 
OK, I've just uploaded 13691.patch. I'm working right now on resolving
complaints about brain-dead CDR's when unanswered=yes; I have another bug
patch
that is introducing a similar patch to the Dial() world.(13892)

This new patch will output a CDR for each attempted dial, and should
include
the disposition of the unconnected call. It is ONLY output if the
"unanswered=yes" is specified in cdr.conf.

I've looked at your patch, and don't think it especially bad; I'd probably
alter it in these ways, though:
  1. Don't try to re-use an existing CDR flag field for this purpose.
DONT_TOUCH is for another situation, and who knows, maybe the 'original'
purpose for which it is intended might collide with this new purpose.
(which is to overrride the single-channel CDR filtering code to force the
CDR to be posted anyway). I think it would be clearer to define a CDR flag
like "POST_ANYWAY" and use that instead.
  2. I think it would be better if this code were wrapped with 
if (!ast_cdr_isset_unanswered()) {...}, because if you do specify
'unanswered = yes', then you'll get a CDR for all attempts, and another for
the total effort. *murf shrugs* ... perhaps, tho, that's what you want.....
 tell me what you think is best here. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-21 15:48 murf           Note Added: 0098362                          
======================================================================




More information about the asterisk-bugs mailing list