[Home]

Summary:ASTERISK-16194: [patch] In agent calls recording, CDR userfield is not updated when the call is transferred
Reporter:Miguel Molina (coolmig)Labels:
Date Opened:2010-06-02 13:55:14Date Closed:2015-03-27 15:31:07
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_agent
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) issue_17447_full_log
( 1) patch_issue_17447_1.6.2.9-rc2.diff
Description:When using agent calls recording, if the call is transferred the userfield on the CDR is not updated with the recording filename.

Steps to reproduce:

1. Enable agent call recording on agents.conf
2. Configure a test queue on queues.conf and transfer extension on dialplan along with the dialplan
3. Make a call to the queue as a customer, and have it answered with an agent.
4. Finish the call without transferring, the CDR userfield will have the recording filename.
5. Repeat the call but this time make the agent transfer the call to the extension you configured. The CDR won't have the recording filename on the CDR.
Comments:By: Paul Belanger (pabelanger) 2010-06-02 14:59:13

Please upload a debug log (see below).
--
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:

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt
By: Miguel Molina (coolmig) 2010-06-02 17:36:02

Full log uploaded.

I enabled agent call recording in agents.conf. I logged in Agent 1001 from SIP extension 100. From SIP extension 101 I made three calls to the test queue:

1. Agent answers, agent hangs up.
2. Agent answers, client hangs up.
3. Agent answers and transfers to extension 1101 where 'tt-monkeys' is played.

Looking at plain text CDR, you can see the three calls. Only the last one doesn't have the recording filename set in the userfield:

"","101","1100","default","101","SIP/101-00000009","Agent/1001","Queue","test|ht","2010-06-02 22:18:17","2010-06-02 22:18:17","2010-06-02 22:18:34",17,17,"ANSWERED","DOCUMENTATION","1275517097.11","agent-1001-1275517097-12.gsm"
"","101","1100","default","101","SIP/101-0000000a","Agent/1001","Queue","test|ht","2010-06-02 22:18:39","2010-06-02 22:18:39","2010-06-02 22:18:51",12,12,"ANSWERED","DOCUMENTATION","1275517119.13","agent-1001-1275517119-14.gsm"
"","101","1100","default","101","SIP/101-0000000b","Agent/1001","Queue","test|ht","2010-06-02 22:19:08","2010-06-02 22:19:08","2010-06-02 22:19:21",13,13,"ANSWERED","DOCUMENTATION","1275517148.15",""

And all three recordings are there:

-rw-r--r-- 1 root root 29K jun  2 17:18 agent-1001-1275517097-12.gsm
-rw-r--r-- 1 root root 20K jun  2 17:18 agent-1001-1275517119-14.gsm
-rw-r--r-- 1 root root 21K jun  2 17:19 agent-1001-1275517148-16.gsm
By: Leif Madsen (lmadsen) 2010-06-03 10:44:48

Confirmed with Russell that we'd expect this to work the way you've described it should work.
By: Miguel Molina (coolmig) 2010-06-09 18:23:53

I've tested this also on 1.6.2.9-rc2 and still happens. You will find a patch for 1.6.2.9-rc2 that solves the issue in a desperate way, because I haven't found the root cause of the problem. chan_agent is really writing the userfield with the filename, but I don't know why or where the userfield is lost in the transfer, if it's in the swap or in the masquerade...
By: Miguel Molina (coolmig) 2010-06-16 11:57:53

I applied the same patch in 1.4 (res_features.c) and it works like a charm in a production server.
By: Matt Jordan (mjordan) 2015-03-27 15:31:00.117-0500

While I know this issue is slightly old, we're going to close this out as "Won't Fix" - although really, this has already been fixed (or at least broken in new and creative ways) in some branches and (hopefully) permanently fixed in other branches.

First, the code where this patch was originally applied no longer exists. That makes it rather difficult to diagnose whether or not the patch is still needed.

Second, the code where this would go now attempts to handle transfers by swapping/caching CDRs around. Whether or not it handles the userfield correctly is unclear - my suspicion (given issues like ASTERISK-20010) is that it doesn't. Unfortunately, the code in {{features.c}} that does handle this is so horribly brittle that merely looking at it sideways is most likely going to cause CDRs to explode. I'm not confident that touching it - particularly with a 'desperate' fixup - is going to yield anything but pain and suffering.

Finally, in Asterisk 12, we re-did all of CDRs. Since bridging is now sane, transfers became sane, which lent some semblance of sanity to the insanity that are CDRs. At the very least, they are broken in new and more creative ways. They do, however, have functional userfields in transfer scenarios.

Ergo, closing this out as "Won't Fix".
By: Matt Jordan (mjordan) 2015-03-27 15:32:00.955-0500

Also, {{chan_agent}} is no more in 12+, so there's that too.