Summary:	ASTERISK-07521: MixMonitor stops after attended call transfer
Reporter:	Rolph (merlijn)	Labels:
Date Opened:	2006-08-11 06:44:22	Date Closed:	2008-10-21 09:23:24
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_mixmonitor
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	we are using MixMonitor within our dialplans to records in/outbound calls. Now we have the following problem: when someone transfers a call to a different user via an attended transfer, MixMonitor stops recording. We see this behaviour also when in the Dialplan a call is placed to a diffent section (something like: Dial(Local/100@other-section-dialplan). We don't see MixMonitor stop when an unattended transfer (blind transfer) is made. Maybe this also has something to do with GROUPCOUNT function was not working properly on attended transfers as well.
Comments:	By: jmls (jmls) 2006-08-11 06:51:14 we also have this issue with monitor and local channels By: Ramon Peek-Fares (ramonpeek) 2006-08-11 11:09:54 For your information: We discovered that the GROUPCOUNT function didn't work on attendant transfers due to a problem with copying the channel variables to the new channel. I suspect the problem with MixMonitor to be related... (But this might be a wrong assumption) By: Joshua C. Colp (jcolp) 2006-08-16 12:16:43 If you put /n at the end of the Dial line for Local/ does it then work? I think I know why... By: Rolph (merlijn) 2006-08-19 17:27:23 With the /n at the end it is indeed working. Is there also a workaround for transfers? By: Joshua C. Colp (jcolp) 2006-08-21 15:08:59 Where is the MixMonitor actually being started, on the Local channel itself? If so without /n then that channel gets masqueraded away and thus the spy goes away as well. Same probably for your group counting situation. Here's my scenario where I saw this happen: exten => 211,1,Dial(Local/212@default) exten => 212,1,MixMonitor(/tmp/blah) exten => 212,n,Dial(Local/333@default) Once the remote party picked up at the 333 extension, the MixMonitor went away since the Local channel went away. By: Rolph (merlijn) 2006-08-21 15:54:54 No, mixmonitor start before the local channel is called: exten => 211,1,MixMonitor(/tmp/blah) exten => 211,2,Dial(Local/212@default) exten => 212,n,Dial(SIP/XYZ) I understand now that I have to use /n in the 1st Dial, one problem solved. However, how do we do this in a attendant transfer. For example: exten => 211,1,MixMonitor(/tmp/blah) exten => 211,2,Dial(SIP/XYZ) exten => 444,1,Dial(SIP/444) Now, when someone calls extension 211 and SIP/XYZ answers the call, the call is being monitored. When XYZ does an attendant transfer to extension 444 and SIP/444 answers the call, MixMonitor stops recording. This is not the behaviour we see when we use an unattended transfer (blind transfer). By: jmls (jmls) 2006-08-21 16:47:12 the above dialplan causes us the same sort of problem - the monitoring stops as soon as an attended transfer takes place By: Joshua C. Colp (jcolp) 2006-09-08 13:56:06 I just put a change into 1.2 and trunk as of revisions 42452 and 42453 that *MAY* help but I think it comes down to the fact that you are starting MixMonitor on a channel that is going to go away if /n is not used in the Local dial line. chan_local has an optimization feature that essentially makes itself go away once each side is bridged to another channel, it just drops out - and since MixMonitor is started on one of those channels then once the channel is gone, MixMonitor is gone. I have however added this bug to my post 1.4 list so I may add an option to chan_local that will allow you to stop this optimization if spies are present on the channel. Peace!