[asterisk-bugs] [Asterisk 0013637]: Missing userfield for Queue call with NO ANSWER

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13637 
====================================================================== 
Reported By:                atis
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13637
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-07 09:42 CDT
Last Modified:              2008-10-08 13:06 CDT
====================================================================== 
Summary:                    Missing userfield for Queue call with NO ANSWER
Description: 
Sample dialplan (attached) has two SIP devices: 

90023 -> Queue(22901) -> 90132

If 90023 hangs up, queue cancels call and resulting CDR is missing
userfield (set before entering queue).


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

---------------------------------------------------------------------- 
 (0093370) murf (administrator) - 2008-10-08 13:06
 http://bugs.digium.com/view.php?id=13637#c93370 
---------------------------------------------------------------------- 
The goal of Queue is much like Dial: that of connecting two channels
together.
The incoming call is "channel", and each of the lines it will ring are
called 'peer' in that code. Every channel automatically gets a CDR. The
hard part is sorting out which CDR's to post, and which to throw away. It
is doing it wrong,
because the incoming channel gets NO_ANSWER, and its disposition is not
updated by app_queue, so the logic throws the main CDR away, and the one
from the ring attempt (peer) is left, and it is getting posted. It's all
messed up, I admit, but I have an idea on how to make those ring attempts
get posted with useful info in them... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-08 13:06 murf           Note Added: 0093370                          
======================================================================