[asterisk-bugs] [Asterisk 0017007]: [patch] RTP Timestamp changes after transfer, but SSRC not and the markerbit ist not set.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17007 
====================================================================== 
Reported By:                addix
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   17007
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for review
Asterisk Version:           SVN 
JIRA:                       SWP-1096 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-11 10:07 CST
Last Modified:              2010-06-25 09:21 CDT
====================================================================== 
Summary:                    [patch] RTP Timestamp changes after transfer, but
SSRC not and the markerbit ist not set.
Description: 
On every SIP Transfer (Example: A calls B / B places A on hold / B calls C
/ A sends Transfer to Asterisk PBX) the Outing RTP Traffic from Asterisk to
the transfer target (RTP to C) is broken. The Asterisk is changing the RTP
Timestamp massivly but the SSRC stays on the old value and the timestamp
marker is also not set. As soon as the new timestamp is smaller than the
old timestamp value the transfer target rejects the RTP Packets after the
transfer (Not really, it's just not played), so i get one way audio.

I experienced that with serveral local SIP-Carriers and Funkwerk Rxxxx
BRI/PRI Mediagateways as transfer target.

Due to my limited Asterisk-Source knowledge i'am not sure that my attached
patch is the correct solution for this problem. After applying my patch the
problem seems to be solved. The Asterisk is changing the SSRC & setting the
Markerbit after the transfer for the RTP-Traffic to the transfer target.




====================================================================== 

---------------------------------------------------------------------- 
 (0123883) twilson (administrator) - 2010-06-25 09:21
 https://issues.asterisk.org/view.php?id=17007#c123883 
---------------------------------------------------------------------- 
I don't think we should add code that checks specifically for a channel
tech type. There are lots of channels that use RTP, so that just isn't a
good way to fix it. Also, the patch confuses me a little as it is 1)
setting a variable 'p' that isn't declared anywhere in the patch, 2) for
some reason it shows things like 'p-rtp' instead of 'p->rtp' and 'p-lock'
instead of 'p->lock'. 3) I'm having trouble finding a version of asterisk
with the variable 'chan_transferee' in chan_sip.c. What version of asterisk
are you using? Is it heavily modified?

I'm also a little confused because if the indicate happens in
ast_channel_maquerade, we should get the CHANGESSRC control frame and then
call ast_rtp_change_source like you are doing in the patch--so they should
be doing the same thing. Is there a way you could try it with the:

+ ast_indicate(clone, AST_CONTROL_SRCCHANGE);
+ ast_indicate(original, AST_CONTROL_SRCCHANGE);

change in ast_channel_masquerade and add some logging to
ast_rtp_change_source to verify it is being called and perhaps to
sip_indicate() where AST_CONTROL_SRCCHANGE is detected? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-25 09:21 twilson        Note Added: 0123883                          
======================================================================