Summary:	ASTERISK-16648: INVITE with Replaces: breaks Monitor() call recording.
Reporter:	Kirill Katsnelson (kkm)	Labels:
Date Opened:	2010-09-05 02:55:27	Date Closed:	2011-06-07 14:04:39
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) log.txt
Description:	An INVITE that Replaces: a dialog that had a channel recording with Monitor() stops recording on that channel. - A peer sends initial INVITE; - (180 trying is sent back) - my dialplan sets up recording of the top channel using Monitor(); - places the call into a queue; - a queue agent answers the call; - (here the calls is answered an a 200 is sent) - (call bridged and recording begins) - In 400-900 ms from our 200 Ok, another INVITE is sent, with a Replaces: header pointing to the dialog established with the initial INVITE And that causes Monitor to stop recording the call. Log file (~900 lines) with some minor commentary added. The second invite is near line 640.
Comments:	By: Stefan Schmidt (schmidts) 2010-09-05 16:11:05 iam not sure cause atleast you should leave the ports in your log to differ Caller A & Caller B. Are they both on IP 99.99.99.99 or is the sip debug only from the origin caller? But if i read the replace header right, the peer (queueagent) with ip 99.99.99.99 which answers the phone want to get the direct media stream: so asterisk wont see the rtp stream anymore. if this is true, how could asterisk still monitor the call? do you have directmedia enabled in your sip.conf? if yes try to disable it. By: Kirill Katsnelson (kkm) 2010-09-05 18:16:15 Thanks for your analysis. Yes you are right in both assumptions: the agent traffic is not part of this log. The agent is on internal network (one of 10.20.0.1xx servers I believe). And the log is for sip debug ip 99.99.99.99 only. I have not replaced ports, only the 2 IP addresses everywhere and the real customer name with the placeholder. Direct media path is not possible because the Asterisk box is behind a NAT router. Asterisk does stay in media path: I know that because call audio is nominal both ways, but the agent does not have any ports it could even expose to listen for outside RTP, because it is not setup for NAT. So I am sure this is an issue in the bridge. If you look at the log carefully, the second INVITE creates a new channel, then masquerade happens, and the original channel is replaced with the new one on the bridge, and last of all becomes a zombie. And that was the channel that owned the monitor. So I think the issue is rather that monitor ownership is not properly transferred to the new channel during masquerade, and monitoring stops when the channel is disconnected from the bridge. I quickly looked at the code, but it does not seem to me like I can easily patch the problem. By: Russell Bryant (russell) 2010-09-09 16:14:26 I believe this is just the expected behavior of Monitor.  Have you looked at using MixMonitor() with AUDIOHOOK_INHERIT()? By: Kirill Katsnelson (kkm) 2010-12-16 01:41:43.000-0600 Sorry, left that off my radar for a horrible while. MixMonitor does not work for us, because we must keep 2 channels of recordings. Our agents are not human, which means we are regression-testing them. The testing corpus is gathered from live conversations. And in this age of TB drives we archive them uncompressed. D-oh! I understand that Monitor() is essentially a frozen obsolete feature. Are there any plans to remove it? Are there plans to add "stereo" non-mixing recording mode to MixMonitor()? This is so essential for us, that I even might be working on that myself, however limited my knowledge of Asterisk guts is. By: Leif Madsen (lmadsen) 2011-02-08 13:57:58.000-0600 As this has moved towards the realm of feature request (although it one I would encourage to be developed), I'm going to close this issue. If you're able to provide a patch, then that would be great. Russell mentioned that it should be created against MixMonitor() to provide the ability to skip the mixing that happens at the end of recording. I would envision that being a flag/option added to MixMonitor(). Please open a new issue and attach the patch for this feature if you're able to provide it. Alternatively you might be able to spark a discussion on the asterisk-users list and see if someone might be interested in providing that functionality. Thanks!