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

Wed Aug 11 22:08:46 CDT 2010

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
Target Version:             1.6.2.12
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-08-11 22:08 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.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0017404 [patch] [regression] audio delay when b...
====================================================================== 

---------------------------------------------------------------------- 
 (0125873) svnbot (reporter) - 2010-08-11 22:08
 https://issues.asterisk.org/view.php?id=17007#c125873 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 281914

_U  trunk/
U   trunk/main/channel.c

------------------------------------------------------------------------
r281914 | jpeeler | 2010-08-11 22:08:44 -0500 (Wed, 11 Aug 2010) | 41
lines

Merged revisions 281913 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r281913 | jpeeler | 2010-08-11 22:03:37 -0500 (Wed, 11 Aug 2010) | 34
lines

  Merged revisions 281912 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2

  ................
    r281912 | jpeeler | 2010-08-11 22:01:38 -0500 (Wed, 11 Aug 2010) | 27
lines

    Merged revisions 281911 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4

    ........
      r281911 | jpeeler | 2010-08-11 22:00:14 -0500 (Wed, 11 Aug 2010) |
20 lines

      Ensure SSRC is changed when media source is changed to resolve audio
delay.

      This change causes the SSRC to change right before the channels are
bridged,
      which is what used to happen. It seems that fixes were made to
attempt limiting
      SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting
the SSRC
      with this change.

      There are two other control frames sent in ast_channel_bridge that
probably
      should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm
going to leave
      this change up to the discretion of resolving issue
https://issues.asterisk.org/view.php?id=17007.

      For reference - old review implementing new control frame SRCCHANGE:
      https://reviewboard.asterisk.org/r/540

      (closes issue https://issues.asterisk.org/view.php?id=17404)
      Reported by: sdolloff
      Patches: 
            bug17404.patch uploaded by jpeeler (license 325)
      Tested by: sdolloff
    ........
  ................
................

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-11 22:08 svnbot         Checkin                                      
2010-08-11 22:08 svnbot         Note Added: 0125873                          
======================================================================