[Home]

Summary:ASTERISK-15790: [patch] RTP Timestamp changes after transfer, but SSRC not and the markerbit ist not set.
Reporter:Addix Internet Services GmbH (addix)Labels:
Date Opened:2010-03-11 10:07:21.000-0600Date Closed:2011-04-26 08:06:38
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1001-reset-SSRC-original-channel.diff
( 1) 1001-sip-reset-transfer-target-rtp.diff
( 2) 1001-sip-reset-transfer-target-rtp-V2.diff
( 3) srcchange.diff
( 4) TransferTT3.pcap
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.





****** ADDITIONAL INFORMATION ******

See attached .pcap Trace RTP Stream 172.17.128.165:13406 (Asterisk) -> 172.17.128.11:10072 (Transfer Target). The Problem begins at packet 2275
See following .patch for chan_sip.c (Just an idea)

<inline patch removed by lmadsen>
Comments:By: Addix Internet Services GmbH (addix) 2010-03-11 10:12:29.000-0600

One error in my example. B sends the transfer :)
By: Leif Madsen (lmadsen) 2010-03-15 09:54:58

Please note that all patches need to be uploaded to the issue tracker in order to track the licensing of patches correctly. If you have no already signed an electronic license, then please do so. You'll see a link at the top of the page for licenses if you haven't already signed. This only needs to be done once.

Also, please test Asterisk 1.4.30 instead of 1.4.29.1 as many issues have been resolved, including those related to transfers.
By: Addix Internet Services GmbH (addix) 2010-03-16 02:09:28

I will test Asterisk 1.4.30 today..
By: Addix Internet Services GmbH (addix) 2010-03-16 04:32:45

I also get these RTP-Errors with Asterisk 1.4.30. Using my attached patch it seems to be fixed.

I improved my patch i little bit & the electronic license is now signed. Any further questions?
By: Leif Madsen (lmadsen) 2010-03-16 14:05:53

Thanks for the information! I don't think anything further is required at this point.
By: Terry Wilson (twilson) 2010-03-18 14:23:12

There have been changes to code related to this in SVN. If you could check out the 1.4 SVN branch and confirm that this is still an issue, I'd appreciate it.
By: Terry Wilson (twilson) 2010-03-18 14:50:48

Also, if it doesn't fix it, I think it might be a better fix to queue an  AST_CONTROL_SRCUPDATE (if it is sufficient to fix the problem) or an AST_CONTROL_SRCCHANGE (but only if absolutely necessary) in ast_channel_masquerade().
By: Addix Internet Services GmbH (addix) 2010-03-23 09:02:30

Today i tried Asterisk SVN-branch-1.4-r253670M which has the same RTP-Problem. I hope i've got enough time & skills to change my patch like twilson described it.
By: Terry Wilson (twilson) 2010-03-23 09:18:07

I went ahead and added a patch that would queue a srcupdate as a demonstration of what the code would look like. You might have to change the AST_CONTROL_SRCUDPATE to and AST_CONTROL_SRCCHANGE if it doesn't fix the issue. Before doing that you might also try changing the "original" to "clone" I sometimes get confused as to which channel is which in a masquerade. :-)  Let me know if you need any more help or if it doesn't work doing some combination of clone/original srcupdate/srcchange.
By: Addix Internet Services GmbH (addix) 2010-05-14 09:37:20

I'am done with testing Asterisk 1.4.31. The bug is still there and my own patch doesn't work anymore. After using twilson's idea...:

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

..it's working. Thanks...
By: Leif Madsen (lmadsen) 2010-05-17 11:33:07

Assigned to twilson for review of what to do with this issue.
By: Niklas Larsson (pnlarsson) 2010-06-20 15:04:13

I had the same issue as the reporter, running chan_sccp and after a transfer there could be oneway audio at random. Applying addix fix solved the issue. I have some wireshark traces if anybody wants to see it.
By: Terry Wilson (twilson) 2010-06-23 14:41:34

I should be able to get to getting this cleaned up and committing soon, just kind of buried for a bit.
By: Terry Wilson (twilson) 2010-06-24 15:40:15

addix: can you verify that you 1) had to change from SRCUPDATE to SRCCHANGE to get the problem to go away and 2) you needed to indicate the SRCCHANGE to both clone and original to get the problem to go away?
By: Addix Internet Services GmbH (addix) 2010-06-25 08:31:54

Sorry for my late answer. After a few weeks of testing we had still a few SSRC problems after the transfer with the Patch of twilson. We had to indicate an "ast_rtp_change_source" for clone and original in the way i did it in the 1st patch (Patching chan_sip.c).

With the newly attached patch we hat no Problems since 4 weeks. (~300 Calls per day)
By: Terry Wilson (twilson) 2010-06-25 09:21:02

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 SRCCHANGE 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?


By: Niklas Larsson (pnlarsson) 2010-06-25 11:15:45

My two cents: I added this to channel.c and added support for AST_CONTROL_SRCCHANGE in chan_sccp (v2). It solved my one way audio after transfer. AST_CONTROL_SRCUPDATE didn't solve the issue.

Index: main/channel.c
===================================================================
--- main/channel.c (revision 272087)
+++ main/channel.c (arbetskopia)
@@ -3866,6 +3866,9 @@
res = 0;
}

+ ast_indicate(clone, AST_CONTROL_SRCCHANGE);
+ ast_indicate(original, AST_CONTROL_SRCCHANGE);
+
ast_channel_unlock(clone);
ast_channel_unlock(original);
By: Terry Wilson (twilson) 2010-06-29 11:31:16

pnarlson: Thanks
addix: I'm going to go ahead and commit the SRCCHANGE patch in the next couple of days. I can't commit a channel-specific patch since it is an issue across multiple channels. If you can elaborate on the problems you were experiencing, I'll try to look at them--but the SRCCHANGE patch should be pretty equivalent to your patch.
By: Addix Internet Services GmbH (addix) 2010-07-19 03:35:01

Hi, i also got this issue with an unpatched Asterisk 1.4.33.1. Now we're using twilson's patch again. Sadly, the RTP to the Transfer Target (Attended transfer) still has the same SSRC after the Transfer. The SSRC of the 1st caller is changed. How can i fix that in channel.c?


By: Addix Internet Services GmbH (addix) 2010-07-19 06:32:15

Here an log with core debug 3 of the attended transfer:

[Jul 19 11:52:51] DEBUG[21126] chan_sip.c: Attended transfer: Will use Replace-Call-ID : 9a1d2b3ccd9c-l3jrne0aa9gp (No check of from/to tags)
[Jul 19 11:52:51] DEBUG[21126] chan_sip.c: SIP transfer: Four channels to handle
[Jul 19 11:52:51] VERBOSE[21126] logger.c:     -- Stopped music on hold on SIP/20-00000014
[Jul 19 11:52:51] DEBUG[21126] channel.c: Set channel SIP/20-00000014 to write format slin
[Jul 19 11:52:51] DEBUG[21126] channel.c: Scheduling timer at 0 sample intervals
[Jul 19 11:52:51] DEBUG[21126] channel.c: Planning to masquerade channel SIP/20-00000014 into the structure of SIP/21-00000016
[Jul 19 11:52:51] DEBUG[21126] channel.c: Done planning to masquerade channel SIP/20-00000014 into the structure of SIP/21-00000016

An result of twilsons Patch:

[Jul 19 11:52:51] DEBUG[21126] rtp.c: Changing ssrc from 632585016 to 665825319 due to a source change
[Jul 19 11:52:51] DEBUG[21126] rtp.c: Changing ssrc from 1278773742 to 666033403 due to a source change

[Jul 19 11:52:51] DEBUG[21126] chan_sip.c: SIP transfer: Succeeded to masquerade channels.
[Jul 19 11:52:51] DEBUG[21126] chan_sip.c: SIP attended transfer: Unlocking channel SIP/21-00000016
[Jul 19 11:52:51] DEBUG[22173] rtp.c: Changing ssrc from 665825319 to 938378332 due to a source change
[Jul 19 11:52:51] DEBUG[22214] channel.c: Got clone lock for masquerade on 'SIP/20-00000014' at 0x817f648
[Jul 19 11:52:51] DEBUG[22214] chan_sip.c: SIP Fixup: New owner for dialogue 9a1d2b3ccd9c-l3jrne0aa9gp: SIP/20-00000014<MASQ> (Old parent: SIP/20-00000014)
[Jul 19 11:52:51] DEBUG[22214] chan_sip.c: Hangup call SIP/20-00000014<MASQ>, SIP callid 9a1d2b3ccd9c-l3jrne0aa9gp)
[Jul 19 11:52:51] DEBUG[22214] chan_sip.c: Updating call counter for incoming call
[Jul 19 11:52:51] DEBUG[22214] chan_sip.c: Call from peer '21' removed from call limit 10
[Jul 19 11:52:51] DEBUG[22214] devicestate.c: Notification of state change to be queued on device/channel SIP/21
[Jul 19 11:52:51] DEBUG[22214] channel.c: Set channel SIP/20-00000014 to write format slin
[Jul 19 11:52:51] DEBUG[22214] channel.c: Set channel SIP/20-00000014 to read format slin
[Jul 19 11:52:51] DEBUG[22214] channel.c: Putting channel SIP/20-00000014 in 64/64 formats
[Jul 19 11:52:51] DEBUG[22214] chan_sip.c: SIP Fixup: New owner for dialogue 3c2ba7978bb1-7014y8rf9so7: SIP/20-00000014 (Old parent: SIP/21-00000016<ZOMBIE>)
[Jul 19 11:52:51] DEBUG[22214] channel.c: Released clone lock on 'SIP/21-00000016<ZOMBIE>'
[Jul 19 11:52:51] DEBUG[22214] channel.c: Done Masquerading SIP/20-00000014 (6)
[Jul 19 11:52:51] DEBUG[22173] channel.c: Didn't get a frame from channel: SIP/21-00000016<ZOMBIE>

SRCUPDATE but no SRCCHANGE on which channel? Change needed?:

[Jul 19 11:52:51] DEBUG[22173] rtp.c: Setting the marker bit due to a source update

[Jul 19 11:52:51] DEBUG[22173] channel.c: Bridge stops bridging channels SIP/21-00000016<ZOMBIE> and SIP/21-00000015


Shold the update of the ssrc better be done after the "Done Masquerading..." in
"int ast_do_masquerade()" ?


By: Terry Wilson (twilson) 2010-07-21 14:42:09

addix: I think you may be right. attaching a patch that does that. let me know if it works for you.
By: Addix Internet Services GmbH (addix) 2010-08-03 10:42:25

twilson: I had do reset the SSRC of the bridged channel too. I think that would be the right way. First tests are looking good...:

--- asterisk-1.4.34/main/channel.c.orig 2010-08-03 15:47:27.372064600 +0200
+++ asterisk-1.4.34/main/channel.c      2010-08-03 15:35:51.002928800 +0200
@@ -4318,6 +4318,13 @@
       if (option_debug)
               ast_log(LOG_DEBUG, "Done Masquerading %s (%d)\n", original->name, original->_state);

+        ast_channel_lock(original->_bridge);
+        ast_indicate(original->_bridge, AST_CONTROL_SRCCHANGE);
+        ast_channel_unlock(original->_bridge);
+        ast_channel_lock(original);
+        ast_indicate(original, AST_CONTROL_SRCCHANGE);
+        ast_channel_unlock(original);
+
       return 0;
}
By: Addix Internet Services GmbH (addix) 2010-08-04 03:44:17

I had to make it a little bit more safe:

--- asterisk-1.4.34/main/channel.c.orig 2010-08-03 15:47:27.372064600 +0200
+++ asterisk-1.4.34/main/channel.c      2010-08-03 15:35:51.002928800 +0200
@@ -4318,6 +4318,17 @@
       if (option_debug)
               ast_log(LOG_DEBUG, "Done Masquerading %s (%d)\n", original->name, original->_state);

+       if (original->_bridge) {
+          ast_channel_lock(original->_bridge);
+          ast_indicate(original->_bridge, AST_CONTROL_SRCCHANGE);
+          ast_channel_unlock(original->_bridge);
+        }
+        if (original) {
+          ast_channel_lock(original);
+          ast_indicate(original, AST_CONTROL_SRCCHANGE);
+          ast_channel_unlock(original);
+        }
+
       return 0;
}
By: Morten Tryfoss (mtryfoss) 2010-08-11 02:18:44

I'm experiencing a similar problem, but here it's a simple Dahdi-IAX native bridge.

Got the following in the log:
[Aug 11 08:56:30] DEBUG[8911] chan_dahdi.c: Requested indication -1 on channel DAHDI/118-1
[Aug 11 08:56:30] DEBUG[8911] features.c: bridge answer set, chan answer set
[Aug 11 08:56:30] DEBUG[8911] chan_dahdi.c: Requested indication 20 on channel DAHDI/118-1
[Aug 11 08:56:30] DEBUG[8911] chan_dahdi.c: Requested indication 20 on channel DAHDI/118-1
[Aug 11 08:56:30] DEBUG[8911] channel.c: Bridge stops bridging channels DAHDI/118-1 and IAX2/pbx2-4661

The channel is answered immidiately when a call comes in(switchboard-number). I've tried MixMonitor() on the dahdi-channel, and there is no sound from the caller.

Might this be the same issue (no masquerading involved in my case)?
By: Digium Subversion (svnbot) 2010-08-11 22:00:12

Repository: asterisk
Revision: 281911

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r281911 | jpeeler | 2010-08-11 22:00:12 -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 ASTERISK-15790.

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

(closes issue ASTERISK-16154)
Reported by: sdolloff
Patches:
     bug17404.patch uploaded by jpeeler (license 325)
Tested by: sdolloff

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

http://svn.digium.com/view/asterisk?view=rev&revision=281911
By: Digium Subversion (svnbot) 2010-08-11 22:01:36

Repository: asterisk
Revision: 281912

_U  branches/1.6.2/
U   branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r281912 | jpeeler | 2010-08-11 22:01:36 -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 ASTERISK-15790.
 
 For reference - old review implementing new control frame SRCCHANGE:
 https://reviewboard.asterisk.org/r/540
 
 (closes issue ASTERISK-16154)
 Reported by: sdolloff
 Patches:
       bug17404.patch uploaded by jpeeler (license 325)
 Tested by: sdolloff
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=281912
By: Digium Subversion (svnbot) 2010-08-11 22:03:36

Repository: asterisk
Revision: 281913

_U  branches/1.8/
U   branches/1.8/main/channel.c

------------------------------------------------------------------------
r281913 | jpeeler | 2010-08-11 22:03:36 -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 ASTERISK-15790.
   
   For reference - old review implementing new control frame SRCCHANGE:
   https://reviewboard.asterisk.org/r/540
   
   (closes issue ASTERISK-16154)
   Reported by: sdolloff
   Patches:
         bug17404.patch uploaded by jpeeler (license 325)
   Tested by: sdolloff
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=281913
By: Digium Subversion (svnbot) 2010-08-11 22:08:44

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 ASTERISK-15790.
     
     For reference - old review implementing new control frame SRCCHANGE:
     https://reviewboard.asterisk.org/r/540
     
     (closes issue ASTERISK-16154)
     Reported by: sdolloff
     Patches:
           bug17404.patch uploaded by jpeeler (license 325)
     Tested by: sdolloff
   ........
 ................
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=281914
By: Terry Wilson (twilson) 2010-08-12 11:59:22

mtryfoss: completely unrelated. Neither IAX nor DAHDI use RTP and the SRCCHANGE control frame only affects channels that use RTP.
By: Terry Wilson (twilson) 2010-08-12 16:23:14

addix: instead of posting the patch in-line, can you upload it so we can verify that you've filled out a license disclaimer for it?
By: Terry Wilson (twilson) 2010-08-12 16:28:06

also, in 1.4 the comment at the top of ast_do_masquerade says that original is assumed to be locked already. It might aslo be safer to use ast_bridged_channel() as it would also work for agent channels as well.
By: Addix Internet Services GmbH (addix) 2010-08-13 02:29:29

I attached the patch as file and sorry, i have no idea how to use ast_bridged_channel() :-/
By: Terry Wilson (twilson) 2010-08-13 11:44:21

addix: I reworked the patch to address the suggestions I made. I removed the lock/unlock and check for original because in 1.4 original should be locked before calling ast_do_masquerade() and therefor has to be both there and locked. I added the if ((bridged = ast_bridged_channel(original))) because ast_bridged_channel will look for the "bridged_channel" callback function on channels like the agent channel, so that if we have an Agent that is really a SIP channel, we'll send the indication to the SIP channel which understands the SRCCHANGE indication, instead of the Agent channel which doesn't.

If you wouldn't mind testing to make sure that I didn't inadvertently break something, I'd appreciate it.
By: Digium Subversion (svnbot) 2010-08-16 14:35:23

Repository: asterisk
Revision: 282430

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r282430 | twilson | 2010-08-16 14:35:22 -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 ASTERISK-15790)
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=282430
By: Digium Subversion (svnbot) 2010-08-16 14:36:23

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 ASTERISK-15790)
 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
By: Digium Subversion (svnbot) 2010-08-16 14:36:27

Repository: asterisk
Revision: 282468

_U  branches/1.8/
U   branches/1.8/main/channel.c

------------------------------------------------------------------------
r282468 | twilson | 2010-08-16 14:36:27 -0500 (Mon, 16 Aug 2010) | 30 lines

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

................
 r282467 | twilson | 2010-08-16 12:32:01 -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 ASTERISK-15790)
   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=282468
By: Digium Subversion (svnbot) 2010-08-16 15:40:53

Repository: asterisk
Revision: 282502

_U  trunk/
U   trunk/main/channel.c

------------------------------------------------------------------------
r282502 | twilson | 2010-08-16 15:40:53 -0500 (Mon, 16 Aug 2010) | 37 lines

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

................
 r282468 | twilson | 2010-08-16 12:53:44 -0500 (Mon, 16 Aug 2010) | 30 lines
 
 Merged revisions 282467 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r282467 | twilson | 2010-08-16 12:32:01 -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 ASTERISK-15790)
     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=282502