[asterisk-bugs] [Asterisk 0014536]: After a caller is processed by app_queue the queue_log logs the hangup as TRANSFER

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14536 
====================================================================== 
Reported By:                aragon
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14536
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Target Version:             1.4.27
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 173594 
Request Review:              
====================================================================== 
Date Submitted:             2009-02-23 19:26 CST
Last Modified:              2009-06-19 00:13 CDT
====================================================================== 
Summary:                    After a caller is processed by app_queue the
queue_log logs the hangup as TRANSFER
Description: 
I'm using agent callback and not channel_agent

In this example ext 222 dials *850 to enter a test queue and ext 233
(agent 1) answers the call. Then 222 hangs up.
But my queue_log logs the hangup reason as TRANSFER instead of
COMPLETEAGENT or COMPLETECALLER

I think I am using revision 173594
====================================================================== 

---------------------------------------------------------------------- 
 (0106689) coolmig (reporter) - 2009-06-19 00:13
 https://issues.asterisk.org/view.php?id=14536#c106689 
---------------------------------------------------------------------- 
I experienced the same issue when I was testing a dialer which is now into
production. After a lot of head crunching I finally got a workaround:

;This context is where the AMI calls are dialed
[dialer-gencall]
exten => _9NXXXXXX,1,NoCDR() ;Don't keep local channel CDRs
exten => _9NXXXXXX,n,Dial(${TRUNK_SALIDA_SIP}/8${EXTEN:1},${TIMEOUT},rto)
exten => _9NXXXXXX,n,Hangup()

;This context is where the outbound connected call is queued
[dialer]
exten => s,1,NoCDR() ;Don't keep local channel CDRs
exten => s,n,Answer()
exten => s,n,Noop(INITIAL UNIQUEID: ${CDR(uniqueid)})
exten => s,n,Wait(0.5) ;(WORKAROUND QUEUE_LOG BUG)
exten => s,n,Noop(FINAL UNIQUEID: ${CDR(uniqueid)})
exten => s,n,Queue(test,h)
exten => s,n,Hangup()

The Wait() workaround makes asterisk "finish" the masquerading process
that occurs with the Local channel generated call, when the SIP channel
that is dialed is answered and connected to the dialer context (proof of
this behavior are the different uniqueid's shown before and after the
Wait). This way, for logging purposes, Queue() sees the masqueraded SIP
channel info instead of the original Local channel. IMHO, when the Wait()
is not there, the masquerading process occurs inside the Queue()
application that makes asterisk see a context change or whatever that makes
log the call that way. All the calls logged as TRANSFER event with zero
duration rendered the information useless.

Your case may be similar, so you can give the workaround a try while the
developers look deeper into this. The workaround has been working month and
a half and counting. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-19 00:13 coolmig        Note Added: 0106689                          
======================================================================