[asterisk-bugs] [Asterisk 0017007]: [patch] RTP Timestamp changes after transfer, but SSRC not and the markerbit ist not set.
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Aug 16 14:36:23 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: closed
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:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2010-03-11 10:07 CST
Last Modified: 2010-08-16 14:36 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...
======================================================================
----------------------------------------------------------------------
(0125985) svnbot (reporter) - 2010-08-16 14:36
https://issues.asterisk.org/view.php?id=17007#c125985
----------------------------------------------------------------------
Repository: asterisk
Revision: 282467
_U branches/1.6.2/
U branches/1.6.2/main/channel.c
------------------------------------------------------------------------
r282467 | twilson | 2010-08-16 14:36:23 -0500 (Mon, 16 Aug 2010) | 23
lines
Merged revisions 282430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16
lines
Send a SRCCHANGE indication when we masquerade
Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
(closes issue https://issues.asterisk.org/view.php?id=17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license
1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
........
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=282467
Issue History
Date Modified Username Field Change
======================================================================
2010-08-16 14:36 svnbot Checkin
2010-08-16 14:36 svnbot Note Added: 0125985
======================================================================
More information about the asterisk-bugs
mailing list