[Home]

Summary:ASTERISK-24470: No Transfer Event in Queue_log after unattended transfer
Reporter:surya (surya_vanam123)Labels:
Date Opened:2014-10-29 22:14:09Date Closed:2014-12-03 16:28:18.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_queue
Versions:1.8.28.2 Frequency of
Occurrence		Constant
Related
Issues:
Environment:cent os , freepbxAttachments:( 0) extensions_additional.conf
( 1) features_general_additional.conf
( 2) features.conf
( 3) freepbx_featurecodes.conf.template
( 4) myDebugLog
( 5) queues_additional.conf
( 6) queues_general_additional.conf
( 7) queues.conf
( 8) sip_general_additional.conf
( 9) sip.conf
Description:I have two Agents Ext 101 and 102 in inbound queue. When made a unattended transfer using feature code ## from 101 to 102 & the transfer event is not generated in queue_log The calls i shown as completed by 101. We are using asterisk version 1.8.28. Please provide a solution for this issue.
Comments:By: Matt Jordan (mjordan) 2014-10-30 09:44:40.827-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please also provide your features.conf, queues.conf, and sip.conf configuration files.
By: surya (surya_vanam123) 2014-10-31 05:08:47.195-0500

As mentioned I attached the required files. Please look into it. I am unable to observe transfer events in the queue_log
By: Richard Mudgett (rmudgett) 2014-10-31 09:24:23.966-0500

The attachments are not visible.  Did you attach them marked as code contributions?  Without an accepted signed licence agreement for code contributions, files marked as contributions are not visible.  Config, logs, and other supporting files don't need to be marked as code contributions.
By: Rusty Newton (rnewton) 2014-11-14 16:59:05.808-0600

I've manually removed the inappropriate contribution status from [~surya_vanam123]'s attachments and they show up now.
By: Matt Jordan (mjordan) 2014-11-14 17:11:13.941-0600

I don't think there's actually a bug here.

In your log, {{SIP/GoFiber1-0000bede}} is the caller in the Queue, calling Local channels {{Local/2002@from-queue-00000012;1}} and {{Local/2015@from-queue-00000013;1}}.

{{Local/2015@from-queue-00000013;2}} dials and is bridged with {{SIP/2015-0000bee0}}.

*Before* {{SIP/2015-0000bee0}} attempts to blind transfer the Queue caller, {{SIP/GoFiber1-0000bede}} hangs up. We can see that here in the log, where they start executing the {{h}} extension:

{noformat}
[2014-10-31 02:46:16] VERBOSE[21657] pbx.c:     -- Executing [h@ext-queues:1] Macro("SIP/GoFiber1-0000bedb", "hangupcall,") in new stack
[2014-10-31 02:46:16] VERBOSE[21657] pbx.c:     -- Executing [s@macro-hangupcall:1] GotoIf("SIP/GoFiber1-0000bedb", "1?theend") in new stack
[2014-10-31 02:46:16] VERBOSE[21657] pbx.c:     -- Goto (macro-hangupcall,s,3)
[2014-10-31 02:46:16] VERBOSE[21657] pbx.c:     -- Executing [s@macro-hangupcall:3] ExecIf("SIP/GoFiber1-0000bedb", "0?Set(CDR(recordingfile)=)") in new stack
[2014-10-31 02:46:16] VERBOSE[21657] pbx.c:     -- Executing [s@macro-hangupcall:4] Hangup("SIP/GoFiber1-0000bedb", "") in new stack
[2014-10-31 02:46:16] VERBOSE[21657] app_macro.c:   == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/GoFiber1-0000bedb' in macro 'hangupcall'
[2014-10-31 02:46:16] VERBOSE[21657] features.c:   == Spawn extension (ext-queues, h, 1) exited non-zero on 'SIP/GoFiber1-0000bedb'
{noformat}

At this point, that channel is gone. They are out of the Queue.

When the agent performs the transfer, what they actually are transferring at this point is their side of the Local channel - which is not the caller. It's not actually in the Queue.

The Queue log is only going to show the {{TRANSFER}} event when the caller is transferred, which is not what occurs in your log - they're already gone.
By: Rusty Newton (rnewton) 2014-11-17 20:27:14.131-0600

I see the same. [~surya_vanam123] are we understanding the issue correctly or did you perhaps provide the wrong set of logs or debug?