|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|
|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 rtp_engine.c: -- Locally bridging SIP/A-00000049 and SIP/B-0000004a
[2011-08-02 13:47:20] VERBOSE rtp_engine.c: -- Locally bridging SIP/inbound-00000047 and SIP/B-0000004a
[2011-08-02 13:47:20] VERBOSE pbx.c: == Spawn extension (inbound, s, 4) exited non-zero on 'SIP/A-00000049<ZOMBIE>'
[2011-08-02 13:47:20] VERBOSE app_mixmonitor.c: == MixMonitor close filestream
[2011-08-02 13:47:26] VERBOSE 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 pbx.c: == Spawn extension (local, B, 1) exited non-zero on 'SIP/inbound-00000047'
[2011-08-02 13:47:26] VERBOSE 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
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.