[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-09 18:40 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
====================================================================== 

---------------------------------------------------------------------- 
 (0101437) aragon (reporter) - 2009-03-09 18:40
 http://bugs.digium.com/view.php?id=14536#c101437 
---------------------------------------------------------------------- 
This code from 172030 revision appears to be suspect but well beyond my
understanding to debug or patch

res_features.c

1511 	 /* better yet, in a xfer situation, find out why the chan cdr got
zapped (pun unintentional) */
1512 	bridge_cdr = ast_cdr_alloc(); /* this should be really, really
rare/impossible? */
1513 	ast_copy_string(bridge_cdr->channel, chan->name,
sizeof(bridge_cdr->channel));
1514 	ast_copy_string(bridge_cdr->dstchannel, peer->name,
sizeof(bridge_cdr->dstchannel));
1515 	ast_copy_string(bridge_cdr->uniqueid, chan->uniqueid,
sizeof(bridge_cdr->uniqueid));
1516 	ast_copy_string(bridge_cdr->lastapp, chan->appl,
sizeof(bridge_cdr->lastapp));
1517 	ast_copy_string(bridge_cdr->lastdata, chan->data,
sizeof(bridge_cdr->lastdata));
1518 	ast_cdr_setcid(bridge_cdr, chan);
1519 	bridge_cdr->disposition = (chan->_state == AST_STATE_UP) ?
AST_CDR_ANSWERED : AST_CDR_NULL;
1520 	bridge_cdr->amaflags = chan->amaflags ? chan->amaflags :
ast_default_amaflags;
1521 	ast_copy_string(bridge_cdr->accountcode, chan->accountcode,
sizeof(bridge_cdr->accountcode));
1522 	/* Destination information */
1523 	ast_copy_string(bridge_cdr->dst, chan->exten,
sizeof(bridge_cdr->dst));
1524 	ast_copy_string(bridge_cdr->dcontext, chan->context,
sizeof(bridge_cdr->dcontext));
1525 	if (peer_cdr) {
1526 	bridge_cdr->start = peer_cdr->start;
1527 	ast_copy_string(bridge_cdr->userfield, peer_cdr->userfield,
sizeof(bridge_cdr->userfield));
1528 	} else {
1529 	ast_cdr_start(bridge_cdr);
1530 	}
1531 	} 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-09 18:40 aragon         Note Added: 0101437                          
======================================================================