Summary:	ASTERISK-03719: [patch] Monitoring stops when channel redirected
Reporter:	Abhishek Tiwari (abhi)	Labels:
Date Opened:	2005-03-20 02:06:55.000-0600	Date Closed:	2008-01-15 15:43:48.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) channel.c.patch
Description:	The monitoring used to stop when the channel was redirected (using manager action). The problem exists in 'ast_do_masquerade' in channel.c The 'monitor' was not copied from the clone and the zombie channel was closing the monitoring. The patch below fixes teh same.
Comments:	By: Kevin P. Fleming (kpfleming) 2005-03-20 09:00:03.000-0600 What will happen if both channels are being monitored when this occurs? Is there a need to 'release' the monitor on the "original" channel before performing the masquerade? By: Abhishek Tiwari (abhi) 2005-03-20 14:46:33.000-0600 Bascially it would depend on the status of the channels. If both the channels are in pbx (something like a app_conference) then there is no need for any masquerading as the redirect is handled within the ast_pbx_run loop. If the channel is not in pbx (like the bridged channel created using dial application), then the monitoring stops. Thus, it is independent of the number of channels being monitored but is dependent on the status (if its running pbx) of the channel. Yes, the original channel has to release the monitor otherwise soft_hangup after the masquerade would close the monitor stream. By: Mark Spencer (markster) 2005-03-20 20:25:26.000-0600 I think this is a bit more complicated actually.  It's not immediately clear which  side should keep its monitoring.  My instinct is to take whichever one already has monitoring, but if they *both* have monitoring, which one do we pick? By: Abhishek Tiwari (abhi) 2005-03-21 18:21:50.000-0600 Monitoring is a channel property rather than a call or a bridge property. Therefore the channel whose monitor variable is set should keep the monitoring. If both the channels have the monitoring on, then they both should keep it later as well. By: Kevin P. Fleming (kpfleming) 2005-03-21 19:49:18.000-0600 They can't _both_ keep it; when a masquerade happens, one of the channels goes away (it is merged into the remaining channel). By: Abhishek Tiwari (abhi) 2005-03-22 20:10:11.000-0600 Since ast_do_masquerade copies the identity of the 'clone' channel into the 'original' channel, thereby overriding the properties of 'original' channel, monitor should also be copied to 'original' from 'clone'. I could not see any case when only the 'monitor' identity need to be preserved for the original channel. If there are such cases then perhaps it should be configurable (may be as a parameter to masquerade)?? Or we just swap the monitors. By: Michael Jerris (mikej) 2005-05-23 21:06:25 Where does this stand?  Is abhi's description accurate? By: Michael Jerris (mikej) 2005-06-28 00:59:02 kevin-  Can you please review this. By: Mark Spencer (markster) 2005-07-31 17:20:46 Updated patch to CVS head and moved the monitor to the clone channel to avoid the possibility of leaking a monitor. By: Russell Bryant (russell) 2005-08-04 19:58:19 fixed in 1.0 as well By: Digium Subversion (svnbot) 2008-01-15 15:43:12.000-0600 Repository: asterisk Revision: 6247 U   trunk/channel.c ------------------------------------------------------------------------ r6247 | markster | 2008-01-15 15:43:11 -0600 (Tue, 15 Jan 2008) | 2 lines Fix monitoring when channel redirected (bug ASTERISK-3719, patch redone) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6247 By: Digium Subversion (svnbot) 2008-01-15 15:43:48.000-0600 Repository: asterisk Revision: 6287 U   branches/v1-0/channel.c ------------------------------------------------------------------------ r6287 | russell | 2008-01-15 15:43:47 -0600 (Tue, 15 Jan 2008) | 2 lines copy the monitor over when masquerading (bug ASTERISK-3719) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6287