[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. 
====================================================================== 
http://bugs.digium.com/view.php?id=14536 
====================================================================== 
Reported By:                aragon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14536
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
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-03-03 08:07 CST
====================================================================== 
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
====================================================================== 

---------------------------------------------------------------------- 
 (0101076) aragon (reporter) - 2009-03-03 08:07
 http://bugs.digium.com/view.php?id=14536#c101076 
---------------------------------------------------------------------- 
Hi,

Given that this issue was probably introduced by revision 172030 and this
revision was written by murf perhaps this bug report could at least be
assigned to murf...
This problem is really starting to affect a lot of my customers; and there
appears to be no way of compensating for this regression in my dial plan.
I'm stuck in a permanent hold pattern before I can upgrade any call center
customers to any Asterisk version including revision 172030. This hurts
because there was a lot of work done here to fix call park and transfer
segfaults and I really that code too...
Naturally I am willing to test any patches and have access to a few
development systems for testing.

Here are the details on revision 172030
I believe it is the 5. in the list that is causing the regression.
Unfortuneatly this is making my call center reports useless because all
answered then hangups are documented as "TRANSFER" in the
/var/log/asterisk/queue_log

Revision 172030 - Directory Listing
Modified Wed Jan 28 18:51:16 2009 UTC (4 weeks, 5 days ago) by murf

This patch fixes h-exten running misbehavior in manager-redirected 
situations.

What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
 AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
 bridge hangup exten code not to run the h-exten there (nor
 publish the bridge cdr there). It will done at the pbx-loop
 level instead.
2. In the manager Redirect code, I set this flag on the channel
 if the channel has a non-null pbx pointer. I did the same for the
 second (chan2) channel, which gets run if name2 is set...
 and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
 running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
   directly in the async_goto routine, which was called from a
   large number of places, and could affect a large number of
   cases, so I tested that fix against a fair number of transfer
   scenarios, both with and without the patch. In the process,
   I saw that putting the fix in async_goto seemed not to affect
   any of the blind or attended scenarios, but still, I was
   was highly concerned that some other scenarios I had not tested
   might be negatively impacted, so I refined the patch to 
   its current scope, and jmls tested both. In the process, tho,
   I saw that blind xfers in one situation, when the one-touch
   blind-xfer feature is used by the peer, we got strange 
   h-exten behavior.  So, I  inserted code to swap CDRs and
   to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
   skipping both publishing the bridge CDR, and running
   the h-exten; they will be done at the pbx-loop (higher)
   level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
   so it's only done if the h-exten is going to be run. A very
   minor performance improvement, but technically correct.


(closes issue http://bugs.digium.com/view.php?id=14241)
Reported by: jmls
Patches:
      14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf
(license 17)
Tested by: murf, jmls 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-03 08:07 aragon         Note Added: 0101076                          
======================================================================