Summary:	ASTERISK-18220: MixMonitor stops recording during attended Transfer
Reporter:	Ishfaq Malik (ishmalik)	Labels:
Date Opened:	2011-08-02 08:35:10	Date Closed:	2012-09-24 15:59:27
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_mixmonitor
Versions:	1.8.3	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOs 5.5 & 5.6	Attachments:
Description:	I have the following scenario... SIP call comes in and gets answered by extension A (MixMonitor is executed as part of this inbound dial plan of the number being called) Extension A puts call on hold and calls extension B Extension A then does an attended transfer of incoming call to extension B I'm finding that the recording only lasts up to the point that the transfer is made. Here is a section of the logs for such a call [2011-08-02 13:47:13] VERBOSE[6475] rtp_engine.c:     -- Locally bridging SIP/A-00000049 and SIP/B-0000004a [2011-08-02 13:47:20] VERBOSE[6475] rtp_engine.c:     -- Locally bridging SIP/inbound-00000047 and SIP/B-0000004a [2011-08-02 13:47:20] VERBOSE[6463] pbx.c:   == Spawn extension (inbound, s, 4) exited non-zero on 'SIP/A-00000049<ZOMBIE>' [2011-08-02 13:47:20] VERBOSE[6464] app_mixmonitor.c:   == MixMonitor close filestream [2011-08-02 13:47:26] VERBOSE[6475] app_macro.c:   == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/inbound-00000047' in macro 'stdexten' [2011-08-02 13:47:26] VERBOSE[6475] pbx.c:   == Spawn extension (local, B, 1) exited non-zero on 'SIP/inbound-00000047' [2011-08-02 13:47:26] VERBOSE[6464] app_mixmonitor.c:   == End MixMonitor Recording SIP/inbound-00000047 Obviously, I've obscured some of the more sensitive details in there The thing to notice here though is that MixMonitor closes the filestream when I hit the transfer button but actually Ends the recording 6 seconds later when the whole call was ended. This seems like inconsistent behaviour and more like an unintentional consequence of changes rather than intended behaviour, i.e. why would you close the filestream yet not end the recording? Also, this is a departure from the behaviour in 1.4 where the entire call would be recorded.
Comments:	By: Leif Madsen (lmadsen) 2011-08-30 15:28:04.901-0500 I agree, with the way you're explaining it, this is not what I would expect to happen. Channel Z --> Dialplan executed (MixMonitor) --> Dialplan executed (Dial Extension A) --> Extension A answers Extension A --> Dialplan executed (Dial) --> Extension B answers Extension A --> transfers channel Z to Extension B In that situation, I would absolutely expect the call to continue being recorded. Basically as long as Channel Z is active, recording should continue (essentially "following" Channel Z). By: Ishfaq Malik (ishmalik) 2011-09-06 03:35:36.994-0500 I have discovered from Digium support that the expected behaviour can be elicited by using Set(AUDIOHOOK_INHERIT(MixMonitor)=yes) but still feel that the default behaviour should be to follow the entire call... By: Matt Jordan (mjordan) 2012-08-27 12:16:55.148-0500 I think we talked a bit about this on the -users list.  If nothing else, it feels like audiohooks should probably be documented on the Asterisk wiki a bit more, including how and when to use them with MixMonitor.