[asterisk-bugs] [Asterisk 0017953]: INVITE with Replaces: breaks Monitor() call recording.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17953 
====================================================================== 
Reported By:                kkm
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17953
Category:                   Channels/chan_sip/Transfers
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.10 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-09-05 02:55 CDT
Last Modified:              2010-09-05 18:16 CDT
====================================================================== 
Summary:                    INVITE with Replaces: breaks Monitor() call
recording.
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 (https://issues.asterisk.org/view.php?id=156#c900 lines) with some
minor commentary added. The second invite
is near line 640.
====================================================================== 

---------------------------------------------------------------------- 
 (0126636) kkm (reporter) - 2010-09-05 18:16
 https://issues.asterisk.org/view.php?id=17953#c126636 
---------------------------------------------------------------------- 
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 the
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-05 18:16 kkm            Note Added: 0126636                          
======================================================================