[Home]

Summary:ASTERISK-14237: MixMonitor stops after transfer from queue
Reporter:Joe Dennick (jdennick)Labels:
Date Opened:2009-05-30 15:25:26Date Closed:2011-06-07 14:00:25
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Exactly the same problem as was reported in Issue 0013538.  In direct station-to-station or DAHDI-to-Station calls, recording will continue even after a transfer.  In our situation, all inbound (DAHDI) calls are going to a queue and then may need to be transferred to a Conference Room so others can collaborate on the issue.  Obviously, we can record the Conference (meetme) rooms individually, but it would be so much easier to just have the original call recording contain the entire transcript.  I'll attach the dial-plan in the "Additional Information" section.  The original recording ends as soon as the Agent hits the pound (#) key to complete the blind transfer (as configured in features.conf).

****** ADDITIONAL INFORMATION ******

Here is a copy (from realtime) of my dial-plan:

Exten => 2814, 1, Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
Exten => 2814, 2, Answer()
Exten => 2814, 3,Set(Record_File=${STRFTIME(${EPOCH}||%G%m%d-%H:%M:%S}_${ARG1})
Exten => 2814, 4, Set(CDR(accountcode)=Test)
Exten => 2814, 5, Set(CDR(UserField)=${Record_File}.wav)
Exten => 2814, 6, MixMonitor(${Record_File}.wav|bW(4))
Exten => 2814, 7, playback(ku)
Exten => 2814, 8, Set(CALLERID(name)="Test")
Exten => 2814, 9, Queue(Test|TtXx)
Comments:By: Sean Bright (seanbright) 2009-05-30 16:00:12

What version of Asterisk? One field says 1.6.1.0 and another says "Older 1.6.0."  So which is it?


By: Joe Dennick (jdennick) 2009-05-31 15:47:54

We're using version 1.6.1.0.  I would have had that in both places, but the "Asterisk Version" is a drop-down on which 1.6.1.0 is not an option.
By: Sean Bright (seanbright) 2009-05-31 18:19:09

Mark, I assigned to you because you are probably the most suited to take a look at this.  If you don't have the time, give me a couple hints on IRC and I will try to take a look at it.
By: Leif Madsen (lmadsen) 2009-06-01 09:28:04

1.6.1.0 is an option -- and seanbright even assigned it there :)
By: Joe Dennick (jdennick) 2009-06-07 10:55:13

I haven't seen any activity on this bug for over a week, but it's still a major concern for us because it doesn't work.  We can consistently reproduce the problem.  Recordings continue after a transfer for a regular call (PSTN to SIP, SIP to PSTN, or SIP to SIP), but any calls going through a queue will stop recording when transferred.  Our agents use MeetMe conferences a lot, so they have a regular need to transfer callers to a conference room so they can consult with others.
By: Leif Madsen (lmadsen) 2009-06-09 08:52:46

Does this only happen with DAHDI / hardware channels, or can this be reproduced with straight up SIP?
By: Leif Madsen (lmadsen) 2009-06-09 08:54:15

I've marked this issue as related to 14971 because the issues sound quite similar, but it is unconfirmed if they really are the same issue.
By: Leif Madsen (lmadsen) 2009-06-10 11:54:11

Unassigned myself and set status to feedback to wait to see if this can be reproduced outside of DAHDI channels since I don't have access to hardware to reproduce this issue myself.
By: Leif Madsen (lmadsen) 2009-06-10 11:56:01

Actually looking at the dialplan again, I should be able to attempt reproducing without DAHDI, but I probably won't get to it this week.
By: Joe Dennick (jdennick) 2009-06-12 10:33:25

Sorry it took so long to respond, but we did test this with SIP to SIP, SIP to DAHDI, etc.  MixMonitor will continue to record calls through (or after) a transfer as expected.  The problem only occurs when a call was processed through a Queue and then transferred by the answering agent.
By: Leif Madsen (lmadsen) 2009-06-16 12:24:54

Additionally, can you provide the entire dialplan that you're using for this issue? You are showing the configuration of how calls are getting to the Queue(), but not showing the dialplan for how the queue is distributing your calls.

If you're using static members, please provide the queues.conf (actually, do that regardless). If you're using AgentLogin(), please provide the login portion of your dialplan. If you're using Local channels, be sure to provide that part of the dialplan.

This way I can reproduce locally quite easily. I have been dealing with these recording issues quite a bit lately, so might have some suggestions as to what you can try to get it working.

Thanks!
Leif.
By: Joe Dennick (jdennick) 2009-06-16 18:37:32

The calls come into the queue directly from a T-1, so there isn't anything happening before the dialplan that I presented above.  We are using Local Channels for the queue agents (via RealTime), and I'll attach one of the queue configs as well as one of the agent configs so you can see it:

Queue Config (from queue_table);
  name = 'KU'
  musicclass = 'beatles'
  announce = ''
  context = 'inbound'
  timeout = '12'
  monitor_type = ''
  monitor_form = ''
  queue_youarenext = ''
  queue_thereare = ''
  queue_callswaiting = ''
  queue_holdtime = ''
  queue_minutes = ''
  queue_seconds = ''
  queue_lessthan = ''
  queue_thankyou = ''
  queue_reporthold = ''
  announce_frequency = '0'
  announce_round_seconds = '0'
  announce_holdtime = 'no'
  retry = '5'
  wrapuptime = '15'
  maxlen = '0'
  servicelevel = '30'
  strategy = 'leastrecent'
  joinempty = ''
  leavewhenempty = ''
  eventmemberstatus = '0'
  eventwhencalled = '0'
  reportholdtime = '0'
  memberdelay = '0'
  weight = '0'
  timeoutrestart = '0'
  periodic_announce = ''
  periodic_announce_frequency = '0'
  ringinuse = 'no'
  setinterfacevar = '0'
  autopause = '1'
 
Agent (member) config (from queue_members table):
  +----------+------------+------------+-----------+---------+--------+
  | uniqueid | membername | queue_name | interface | penalty | paused |
  +----------+------------+------------+-----------+---------+--------+
  |      460 | Caeli      | KU         | SIP/2841  |       5 |      0 |
  |      863 | Julie      | KU         | SIP/2842  |       4 |      0 |
  |      295 | Ngoc       | KU         | SIP/2843  |       3 |      0 |
  |      450 | Kathy      | KU         | SIP/2844  |       3 |      0 |
  |      562 | Jenn       | KU         | SIP/2845  |       5 |      0 |
  |      271 | Cris       | KU         | SIP/2846  |       1 |      0 |
  |      301 | Sandy      | KU         | SIP/2847  |       1 |      0 |

I think these are the answers to your questions, but if not, please do not hesitate to ask for more details.  And thank you for your assistance in this!

BTW: I was a good friend of Rich Adamson, in fact it was he who got me involved with Asterisk in the first place.  This particular project is for his company (Network Partners, Inc.).

Joe
By: Leif Madsen (lmadsen) 2009-06-16 18:58:35

You say you're using Local Channels for the agents, but I don't see where you're using the Local channels? Looks like in your queue_members table you're just using static queue members?

Awwww... nostalgia!
By: Cristian Dimache (cristiandimache) 2009-06-18 03:07:35

I have run into the same issue.

I have realtime queues and realtime queue_members.

AUDIOHOOK_INHERIT works with this dialplan:
exten =>q28,1,MixMonitor(${UNIQUEID}.WAV)
exten =>q28,2,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
exten =>q28,3,Dial(SIP/201)

but it does not work with this one:
exten =>q28,1,MixMonitor(${UNIQUEID}.WAV)
exten =>q28,2,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)
exten =>q28,3,Queue(q28)

The flow is the same: extension SIP/201 answers (after Dial or after the Queue) and then transfers to SIP/200.
By: Leif Madsen (lmadsen) 2009-06-22 09:07:07

Reassigned to dvossel since this issue has been confirmed by someone else. Thanks!
By: David Vossel (dvossel) 2009-06-22 15:42:15

I'm able to reproduce this in Trunk.  The problem only occurs for me when transferring from the queue to a meetme conference, but not when transferring from the queue to another phone extension.  I'm not sure what the difference is, but I'll figure it out.
By: David Vossel (dvossel) 2009-06-22 16:03:30

from additional information:
"Exten => 2814, 6, MixMonitor(${Record_File}.wav|bW(4)) "

Using MixMonitor with the 'b' option will not work in meetme conferences.  This is documented.  Taking the 'b' option out let me continue to record after transferring from the queue to a conference.

Is this the problem, or am I missing something?  Do the recordings stop for any transfer, or just for transfers to conferences?
By: Cristian Dimache (cristiandimache) 2009-06-23 00:08:17

I didn't test with trunk, but with 1.6.1.
If the call from A enters a queue, an agent B answers it, and then transfers the call to C, MixMonitor stops at the point where the transfer is completed (when A and C are bridged).
However, if the call from A is made directly to B (without a queue) and B transfers to C, MixMonitor records the part of the call after the bridge between A and C.
By: David Vossel (dvossel) 2009-06-23 11:13:33

I've spent some more time trying to reproduce this issue was able to reproduce it with the 1.6.1.0 tag using queues and attended transfers.  However, after updating to the latest 1.6.1 code I was unable to reproduce the issue.

Can someone please verify that updating to the latest 1.6.1 code does indeed resolve the issue.  Also, as I noted before, using MixMonitor with the 'b' option and transferring to a conference room is documented NOT to work.


By: Joe Dennick (jdennick) 2009-06-23 11:26:34

Last Saturday, I updated to the latest stable, which is 1.6.1.1, and the problem still exists.  I didn't realize that the 'b' option on MixMonitor would cause problems, however, so I will remove that and see if it solves the problem.  Thank you for all of the research and input.
By: Cristian Dimache (cristiandimache) 2009-06-24 15:39:59

The problem is still there in 1.6.2.0-beta3
By: Leif Madsen (lmadsen) 2009-06-24 15:49:13

jdennick:  1.6.1.1 is only a security release -- there are no changes beyond 1.6.1.0 other than that security change. You will need to test with 1.6.1 branch as dvossel suggests.

cristiandimache: the same issue as above potentially -- 1.6.2.0-beta3 is an entirely separate branch (1.6.2) from that of 1.6.1. Please test with 1.6.1 latest branch to determine if this is still an issue.

If you are going to test with 1.6.2, I suggest you test with 1.6.2 branch.

(for more information on version numbering, please see http://www.asterisk.org/node/48602)
By: Leif Madsen (lmadsen) 2009-07-13 10:30:13

Closed due to lack of response. I'm closing this for now since this issue may already be resolved in the latest Asterisk from SVN. If you are still having this issue, please open a new issue and mention it is related to this issue. Thanks!