[Home]

Summary:ASTERISK-12764: [patch] Recording stops after Transfer when using MixMonitor()
Reporter:Mark Brooker (mbit)Labels:
Date Opened:2008-09-23 00:02:08Date Closed:2008-12-19 17:36:44.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13538.patch
Description:When an extension is set to record and the call is transferred to another extensions which is also recording, the recording stops as soon as the call is transferred.
Comments:By: Mark Michelson (mmichelson) 2008-10-08 17:14:26

I'm going to need some clarification here.

I take it that when you say that an extension is "set to record" you mean that you are using the MixMonitor app in the dialplan. Is this correct?

Second of all, you say that you transfer to a second extension which is also recording, does this mean that you are using the MixMonitor application in the second extension, too?

Does the recording stop and then start again or does it just stop? Also, what type of transfer are you using? Blind? Attended? Using a feature code as defined in features.conf? Using the transfer button on a SIP phone?

Thank you!
By: Mark Brooker (mbit) 2008-10-08 17:48:34

Yes mix monitor is in the dial plan. Basically SIP phone A receives a call from zap1. SIP phone A attended transfers to SIP phone B. Both Sip phones have recording enabled. Now Sip phone B is talking to zap1 however the call is not being recorded.
By: Gregory Hinton Nietsky (irroot) 2008-10-21 04:20:48

i have a dialplan with monitor in it a attended transfer is not the simplest and most predictiable scenario it may be usefull to 'set verbose 3' place the call and attach the trace to the bug report.

i dont see this problbem in production then again im stoping the recording and restarting it on each transfer so i can trace the call in multiple files through the system.
By: Leif Madsen (lmadsen) 2008-10-21 09:25:04

I agree with irroot. Some additional information is required here. Please attach the relevant dialplan sections and console output in order to move this issue forward. Thanks!
By: Mark Michelson (mmichelson) 2008-10-24 16:39:00

Besides the information that blitzrage asked for, I think it is also important to distinguish if you are using SIP transfers (i.e. pressing the transfer button on a SIP phone) or built-in transfers (i.e. pressing a DTMF sequence defined in features.conf).

Thanks!
By: Andrey Solovyev (corruptor) 2008-10-29 04:29:57

We also have this problem. I can also say that recording after attended transfer worked on erlier versions of 1.4.x.
I mean built-in attended transfers. Blind transfers work ok.
Scenario is simple
1) A (SIP/123) calls B (MixMonitor is enabled on channel SIP/123-asdfgh12 and recording is started)
2) B presses button defined in features.comf for attended transfers and calls C. A is on hold.
3) C answers. B talks to C.
4) B hangs up the calls. A (SIP/123-asdfgh12) and C are bridged. But for some reason MixMonitor stop recording channel SIP/123-asdfgh12. We can see this in CLI (== End MixMonitor Recording SIP/123-asdfgh12).
By: Henrique Grolli Bassotto (guaxinim) 2008-11-12 08:34:40.000-0600

confirmed on newer versions (1.4.22)
By: Mark Michelson (mmichelson) 2008-11-12 13:45:05.000-0600

As an update, I believe I have found the source of this issue, but the problem is that there is another bug in the 1.4 branch right now which is preventing me from doing any real good tests. Once I clear the other bug up, I can get back to this one.
By: Mark Michelson (mmichelson) 2008-11-14 12:02:13.000-0600

I have uploaded a patch for testing. This worked for me on my test calls. Please report if this solves the issue for you as well. Thank you!
By: Leif Madsen (lmadsen) 2008-11-18 09:40:51.000-0600

initial indications are that this patch doesn't change the functionality, but I will be re-verifying that when I return from the gym
By: Leif Madsen (lmadsen) 2008-11-18 12:11:30.000-0600

As was recently discussed on IRC... it seems this approach (the one in the patch provided) will not actually solve the issue described here. Some work with audiohooks appears to be needed which is slightly more involved.
By: Mark Michelson (mmichelson) 2008-11-18 17:36:53.000-0600

file expressed interest in implementing some audiohook magic for this issue so I have assigned it to him.
By: Andrey Solovyev (corruptor) 2008-11-19 09:33:02.000-0600

Is it possible to continue recording if SIP transfer (SIP REFER) is made?
Th scenario is the same as I've described above but instead of attended transfer we do SIP transfer.
The behaviour of MixMonitor is also the same. Channel is alive but stops recording after transferer hangs up.
This makes impossible to monitor calls when tranfers are always made (e.g. clients call secretary and she transfers to someone else).
By: Mark Michelson (mmichelson) 2008-11-19 09:39:46.000-0600

corruptor: No, that won't work either. The issue is that the audiohooks on the incoming channel (audiohooks are what MixMonitor uses to record calls) are lost during the final step of any attended transfer, whether it is using the feature code defined in features.conf or using the transfer button on a SIP phone.


By: Leif Madsen (lmadsen) 2008-11-19 10:07:13.000-0600

What about using Monitor() instead of MixMonitor()?  I've had the inverse issue where the call is still recorded after the attended transfer with using Monitor().
By: Henrique Grolli Bassotto (guaxinim) 2008-11-19 10:18:10.000-0600

"What about using Monitor() instead of MixMonitor()? I've had the inverse issue where the call is still recorded after the attended transfer with using Monitor()"

It works (just after that patch has been applied). But the recording quality is questionable.

We put in production here as a emergencial solution, still need the definitive solution work with MixMonitor.
By: Mark Michelson (mmichelson) 2008-12-05 10:22:51.000-0600

I have reassigned this to myself since file has been very busy with other work lately.
By: Digium Subversion (svnbot) 2008-12-08 09:39:56.000-0600

Repository: asterisk
Revision: 161676

_U  team/mmichelson/issue13538/
U   team/mmichelson/issue13538/include/asterisk/audiohook.h
U   team/mmichelson/issue13538/main/audiohook.c

------------------------------------------------------------------------
r161676 | mmichelson | 2008-12-08 09:39:56 -0600 (Mon, 08 Dec 2008) | 5 lines

First batch of work for fixing issue ASTERISK-12764. This passes the
"it compiles" test, but it most likely has bugs in it. I have
not yet tested its functionality at all.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=161676
By: Mark Michelson (mmichelson) 2008-12-09 15:29:02.000-0600

For those following this issue, I have an update. I have started a branch to correct this issue. It may be checked out from the following location using subversion:

http://svn.digium.com/svn/asterisk/team/mmichelson/issue13538

If you install this and start Asterisk, you can run "core show function AUDIOHOOK_INHERIT" and see how to use the AUDIOHOOK_INHERIT function to allow for MixMonitor to stay alive during a transfer. The support is not 100% complete yet because the functionality described to allow for the final leg of a transfer to block the inheritance of an audiohook is not yet working.

Caution: This branch is based off of Asterisk trunk, not Asterisk 1.4. It is not a good idea to run this in production, and upgrading to it from 1.4 may require work to update your dialplan as well as any external Asterisk modules you may be using.

I will eventually make a patch for 1.4 and post it here, but I want to go through the process of testing and review prior to doing that. Thanks for your patience
By: Mark Michelson (mmichelson) 2008-12-15 14:27:14.000-0600

An update. I have run across a snag in the issue13538 branch. Unfortunately, due to the way masquerades work, it appears that the original method I had set up for letting a channel choose to not inherit audiohooks is not working and making it work may not be possible under the current scheme. However, the ability to allow an audiohook to inherit to a new channel works well from my testing.
By: Mark Michelson (mmichelson) 2008-12-18 16:49:07.000-0600

I have uploaded my work on this issue to reviewboard

http://reviewboard.digium.com/r/102/

You can follow along with any comments made there, or you can feel free to make comments yourself. You should be able to log into reviewboard using your username and password you use for bugs.digium.com

Btw, on reviewboard, I'm known as mmichelson.
By: Mark Michelson (mmichelson) 2008-12-18 16:50:02.000-0600

I'm changing the status to "ready for review" since I have placed code on reviewboard. Note that the patch on this issue is *not* the same as the code that is on reviewboard.
By: Mark Michelson (mmichelson) 2008-12-19 16:14:43.000-0600

If you check out the reviewboard comments, I have made all the corrections necessary to get this committed.

The even better news is that since this patch does not introduce any invasive changes to the code, it has been approved for inclusion in all released versions of Asterisk.

The next message you see here should hopefully be the svnbot showing the fixes being committed.
By: Digium Subversion (svnbot) 2008-12-19 16:26:52.000-0600

Repository: asterisk
Revision: 166092

U   trunk/CHANGES
A   trunk/funcs/func_audiohookinherit.c
U   trunk/include/asterisk/audiohook.h
U   trunk/main/audiohook.c
U   trunk/main/channel.c

------------------------------------------------------------------------
r166092 | mmichelson | 2008-12-19 16:26:52 -0600 (Fri, 19 Dec 2008) | 28 lines

Adding a new dialplan function AUDIOHOOK_INHERIT

This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor
continue recording the call even after the transfer
has completed.

It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.

(closes issue ASTERISK-12764)
Reported by: mbit
Patches:
     13538.patch uploaded by putnopvut (license 60)
 Tested by: putnopvut

Review: http://reviewboard.digium.com/r/102/


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166092
By: Digium Subversion (svnbot) 2008-12-19 17:04:02.000-0600

Repository: asterisk
Revision: 166097

_U  branches/1.6.0/
U   branches/1.6.0/CHANGES
U   branches/1.6.0/include/asterisk/audiohook.h
U   branches/1.6.0/main/audiohook.c
U   branches/1.6.0/main/channel.c

------------------------------------------------------------------------
r166097 | mmichelson | 2008-12-19 17:04:02 -0600 (Fri, 19 Dec 2008) | 44 lines

Merged revisions 166092,166095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r166092 | mmichelson | 2008-12-19 16:26:16 -0600 (Fri, 19 Dec 2008) | 28 lines

Adding a new dialplan function AUDIOHOOK_INHERIT

This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor
continue recording the call even after the transfer
has completed.

It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.

(closes issue ASTERISK-12764)
Reported by: mbit
Patches:
     13538.patch uploaded by putnopvut (license 60)
 Tested by: putnopvut

Review: http://reviewboard.digium.com/r/102/


........
r166095 | mmichelson | 2008-12-19 16:40:57 -0600 (Fri, 19 Dec 2008) | 5 lines

Remove the verbatim tag from the author line

I could have sworn I already did that before, though...


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166097
By: Digium Subversion (svnbot) 2008-12-19 17:07:29.000-0600

Repository: asterisk
Revision: 166098

_U  branches/1.6.1/
A   branches/1.6.1/funcs/func_audiohookinherit.c
U   branches/1.6.1/include/asterisk/audiohook.h
U   branches/1.6.1/main/audiohook.c
U   branches/1.6.1/main/channel.c

------------------------------------------------------------------------
r166098 | mmichelson | 2008-12-19 17:07:28 -0600 (Fri, 19 Dec 2008) | 44 lines

Merged revisions 166092,166095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r166092 | mmichelson | 2008-12-19 16:26:16 -0600 (Fri, 19 Dec 2008) | 28 lines

Adding a new dialplan function AUDIOHOOK_INHERIT

This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor
continue recording the call even after the transfer
has completed.

It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.

(closes issue ASTERISK-12764)
Reported by: mbit
Patches:
     13538.patch uploaded by putnopvut (license 60)
 Tested by: putnopvut

Review: http://reviewboard.digium.com/r/102/


........
r166095 | mmichelson | 2008-12-19 16:40:57 -0600 (Fri, 19 Dec 2008) | 5 lines

Remove the verbatim tag from the author line

I could have sworn I already did that before, though...


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166098
By: Digium Subversion (svnbot) 2008-12-19 17:35:43.000-0600

Repository: asterisk
Revision: 166157

U   branches/1.4/CHANGES
U   branches/1.4/channels/chan_sip.c
A   branches/1.4/funcs/func_audiohookinherit.c
U   branches/1.4/include/asterisk/audiohook.h
U   branches/1.4/main/audiohook.c
U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r166157 | mmichelson | 2008-12-19 17:35:43 -0600 (Fri, 19 Dec 2008) | 9 lines

Backport of AUDIOHOOK_INHERIT for Asterisk 1.4

(closes issue ASTERISK-12764)
Reported by: mbit
Patches:
     13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166157
By: Digium Subversion (svnbot) 2008-12-19 17:36:17.000-0600

Repository: asterisk
Revision: 166158

_U  trunk/

------------------------------------------------------------------------
r166158 | mmichelson | 2008-12-19 17:36:17 -0600 (Fri, 19 Dec 2008) | 16 lines

Blocked revisions 166157 via svnmerge

........
r166157 | mmichelson | 2008-12-19 17:34:57 -0600 (Fri, 19 Dec 2008) | 9 lines

Backport of AUDIOHOOK_INHERIT for Asterisk 1.4

(closes issue ASTERISK-12764)
Reported by: mbit
Patches:
     13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166158
By: Digium Subversion (svnbot) 2008-12-19 17:36:42.000-0600

Repository: asterisk
Revision: 166159

_U  branches/1.6.1/

------------------------------------------------------------------------
r166159 | mmichelson | 2008-12-19 17:36:42 -0600 (Fri, 19 Dec 2008) | 23 lines

Blocked revisions 166158 via svnmerge

................
r166158 | mmichelson | 2008-12-19 17:36:22 -0600 (Fri, 19 Dec 2008) | 16 lines

Blocked revisions 166157 via svnmerge

........
r166157 | mmichelson | 2008-12-19 17:34:57 -0600 (Fri, 19 Dec 2008) | 9 lines

Backport of AUDIOHOOK_INHERIT for Asterisk 1.4

(closes issue ASTERISK-12764)
Reported by: mbit
Patches:
     13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut


........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166159