[asterisk-bugs] [Asterisk 0012924]: ap_queue hangs up caller

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12924 
====================================================================== 
Reported By:                snyfer
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12924
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0-beta9 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-24-2008 01:44 CDT
Last Modified:              06-28-2008 16:48 CDT
====================================================================== 
Summary:                    ap_queue hangs up caller
Description: 
ap_queue hangs up the caller after a queuemember answered even, if the
queuemember did not hear the anouncement of the queue!
 
So if a queuemember answeres a call -> hears the holdtime -> waits for the
anouncement and hangs up at that point, the caller is hung up, 
instead of getting back in the queue and waiting for the next agent
(member) to call!

This worked in asterisk v1.2.x and does not anymore in v1.6.0 Beta 9
 

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

---------------------------------------------------------------------- 
 putnopvut - 06-28-08 16:48  
---------------------------------------------------------------------- 
I have finally found the source of the problem. The simple answer is that
there is a built-in 500 ms delay when a channel answers in 1.6.0. This
delay is not in 1.2 or 1.4. app_queue plays the "beep" file during this
delay and actually finishes playing it before the delay has finished.
During this delay, all frames sent to the channel are handled by the core
and dropped. Because of this, the hangup is not detected until the calling
and called channels are bridged. At this point, app_queue thinks that the
caller has successfully contacted a queue member, the queue member has hung
up, and the caller can safely be removed from the queue. If, however, the
sound file played is longer than the 500 ms delay, then the channel driver
would alert the core that the channel has been hung up, app_queue would
then detect the hangup during the playback, and app_queue would return the
caller to the queue.

I don't know why this 500 ms delay was added yet, but I assume it was done
with good intentions in mind. I will start querying developers about why
the delay was added and if there is a reasonable way to work around this
delay from within app_queue. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-28-08 16:48  putnopvut      Note Added: 0089407                          
======================================================================