Summary:	ASTERISK-05614: Agent calls not recorded after transfer
Reporter:	jmls (jmls)	Labels:
Date Opened:	2005-11-15 17:09:31.000-0600	Date Closed:	2011-06-07 14:10:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_agent
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	We monitor (record) all inbound calls to our queues, using recordagentcalls=yes and recordformat=gsm in the agents.conf file. If a call comes in to a queue, and is answered by an agent (let's say 6001) then I have a recording for agent-6001-xxx-yyy.gsm.  if the agent wants to transfer the call to another agent (an attended xfer), then the recording is terminated at the exact time the inbound call is transferred to the second agent. ****** ADDITIONAL INFORMATION ****** I've also tried using the Monitor command: 1) Incoming Call Answered By Extension A 2) Conversation between caller and A 3) A decides to transfer call to B 4) A talks to B 5) A transfers to B 6) B has conversation with caller 7) Hangup. This results in the full call being recorded. (up to point 7) 1) Incoming Call Answered By Queue 2) Queue Calls Agent A 3) Agent A confirms ready to talk 4) Conversation between caller and Agent A 5) Agent A decides to transfer call to Extension B 6) Agent A talks to extension B 7) Agent A transfers to extension B 8) Extension B has conversation with caller 9) Hangup. This results in the call being recorded, but only up to point 6 (actually to point 5 - between 5 and 6 is only the sound from the caller, i.e. not the conversation between A and B - that's a different call) As you can see, we are now missing the conversation between the caller and Extension B. I would do away with the agent recording and record through the dialplan, but I have some queues that use members and not agents.
Comments:	By: BJ Weschke (bweschke) 2005-11-15 17:17:57.000-0600 Right. a Monitor command is going to end it's monitoring when the bridging of two channels ends. This is what happens when you transfer a call. One way to accomodate what you're looking to do would be to setup another monitor of a call once the transfer happens and then you can merge the two files together into one. By: jmls (jmls) 2005-11-15 17:35:36.000-0600 I understand what you are saying, but a) Why does it work with the scenario above using the Monitor command, but not with the agent recording b) How do I setup another monitor when the transfer happens ? My dialplan is thus [AgentQ] ; this records the initial call to the initial agent exten => _6XXX,1,Dial(SIP/${EXTEN}) exten => _6XXX,2,Hangup() [from-floor] ;this records the conversation between 2 agents during the attended xfer exten => _6XXX,1,Answer() exten => _6XXX,2,Monitor(gsm,INTERNAL-${CALLERIDNUM}-${EXTEN}-${UNIQUEID}) exten => _6XXX,3,Dial(SIP/${EXTEN}) exten => _6XXX,4,Hangup() but where do I put the monitor to record the conversation between the initial caller and the extension the call was transferred to ? BTW - this used to work, with CVS head from March this year. By: BJ Weschke (bweschke) 2005-11-15 18:06:44.000-0600 Because when app_queue makes a call to the agent, and then the agent transfers the call away, app_queue believes that the call on that channel is now over once the call is transferred and, as a result, ends the monitor. And you're saying that the atxfer breaks the monitor again once the initial caller is bridged with the third party, right? That might make sense since it's another bridge transition for the call. By: Kevin P. Fleming (kpfleming) 2005-11-15 21:00:15.000-0600 Actually, in this case it's chan_agent initiating the recording (not app_queue), and as soon as the channel leaves its control (because the call was transferred away from the agent) then the recording will stop. One option would be to have Agent A transfer to Agent B via a special extension number (not their normal extension number) that sends the call to Agent/<number> instead of directly to their SIP device. This will send the second call leg back into chan_agent, and it will record that conversation as well, although it will go into a separate recording file. By: jmls (jmls) 2005-11-16 00:39:55.000-0600 Unfortunately, not all of the extensions that are being transferred to are Agents.    Isn't there a difference between a hangup and a transfer ? If there is could we not determine whether or not to terminate the recording ? I would have thought that a recording would / should continue until the original channel (i.e. the inbound call) was terminated / hung up. By: jmls (jmls) 2005-11-16 01:03:14.000-0600 Ah, here's a thought - could I not start the monitoring process before the calls go into the call queue ? Because the recording is on the original inbound channel then surely it will not stop recording until it is hung up. One problem that I can see is that I don't know the agent number before it goes into the queue. Would ChangeMonitor work if I used it within the context for AgentCallBack, or does the Local/ bugger things up ? By: Kevin P. Fleming (kpfleming) 2005-11-16 12:49:56.000-0600 You have found the issue: monitoring is performed on 'channels', not on 'calls'. If you start monitoring the call as it gets delivered to the agent, then the monitor is running on the agent's channel, not the caller's channel. When the agent's channel goes away (because they transferred the call to someone else), the monitoring stops. You can certainly put the monitor on the caller's channel, but you'd have to match up recording file names with agent number(s) after the fact using call unique IDs and the queue log. By: jmls (jmls) 2005-11-16 12:57:00.000-0600 Yeah, figured that. What I really need is a mechanism to change the monitor filename of the channel that the agent is bridged to. The ChangeMonitor dialplan command only changes the current channel. However, the ChangeMonitor manager command allows you to change the monitor filename of the channel you want. Hmm. I think I'm going to add an optional parameter to the ChangeMonitor dialplan command. Then, in the agent callback context I can change the monitor filename of the channel the agent is connected to. Is that a sound plan ? I know it's an addition, so it won't make it into 1.2, but it will be a simple patch (methinks, having enough knowledge of C to be dangerous rather than productive) By: Kevin P. Fleming (kpfleming) 2005-11-16 13:00:58.000-0600 Well, it doesn't sound awful... but it would really better to manipulate the file names off line. How are you going to handle the case where two agents are involved in the call, when you can only put one of their agent IDs into the filename? By: jmls (jmls) 2005-11-16 13:09:23.000-0600 A) The main priority is to have the full conversation of the inbound call recorded. This we can do without any changes by simply starting the monitor before we put it into the queue. B) We like to have the agent id in the filename. We have a custom call listening database that is searchable by agentid (for performance reviews etc). For my purposes -> 1) Incoming call: start monitoring. Filename is in-queue-callerid-uniqueid 2) agent answers call Filename is changed to in-queue-callerid-uniqueid-agentnum 3) agent transfers call filename is changed to in-queue-callerid-uniqueid-agentnum-agentnum or even in-queue-callerid-uniqueid-agentnum-extensionnum etc etc thus by simply looking at the filename we know the path the call took through our system (even if it was transferred several times) By: Kevin P. Fleming (kpfleming) 2005-12-12 19:51:55.000-0600 Suspending due to lack of activity; it seems that the poster and the others in the community are not interested enough in making this change to provide a patch :-)