Summary:	ASTERISK-20098: P2P bridging can cause the SSRC of a RTP session to change during a call
Reporter:	Morten Tryfoss (mtryfoss)	Labels:
Date Opened:	2012-07-09 02:04:15	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) p2pbridge.diff
Description:	P2P bridging can cause the SSRC id for an RTP stream to change during an active call. This can make some equiptment unhappy. I've added a configuration option so that this can be turned off. See the attached patch.
Comments:	By: David Woolley (davidw) 2012-07-09 05:42:19.882-0500 SSRC changes should not make things unhappy.  In fact, Cisco phones are actually made unhappy by changes in timing source (timestamp jumps) which are not associated with SSRC changes.  We had to add an option to make SSRC chang on every marker bit change, but we did so on too old a version to make it worth submitting a patch for this. SSRC SHOULD change every time there is a discontinuity in the timestamps, e.g. switching from internal tone to through audio. By: Morten Tryfoss (mtryfoss) 2012-07-09 05:48:11.837-0500 Ok. This is related to Microsoft Lync. We're trying to get a sip trunk setup with asterisk certified with Microsoft, and this needs to be done in order to get it to work as they require. I also understand that you maybe don't want to include this in the official asterisk release, but I thought I would post it here if someone else ran into the same problem. By: Morten Tryfoss (mtryfoss) 2012-07-09 05:53:16.450-0500 One more thing. In our case this is related to the switch from early media to call answered. Early media doesn't seem to get P2P-bridged. A fix for that would probably also be a solution. By: David Woolley (davidw) 2012-07-10 05:16:56.915-0500 Native bridging early media would be a radical change in the internal design. The big problem you have with avoiding SSRC changes on an early media to peer to peer bridging transition is that SSRC is not carried in the internal voice frame structures, so the sending side and receiving side SSRC are completely decoupled.  On the transition to native bridging, SSRC starts being passed through unchanged.  I tend to think that SSRC should be passed through the "backplane", but that probably involves changes to all technology drivers. Although this then becomes a support issue, I think the only approach that you could apply is to defeat native bridging.  I'm not sure if it is sufficient to force tone detection, or whether you would need a non-optimising local channel. I still don't see how a change in SSRC without a real change of timing soure causes any more problems that the change in SSRC between call progress and speech.  I consider the fact that Asterisk doesn't change SSRC for such a transition, when not native bridging, to be a bug in Asterisk. By: Matt Jordan (mjordan) 2012-07-16 08:37:11.289-0500 I don't mind acknowledging this issue to put it in Open status, but I don't see this as a patch that we would want to put into Asterisk. David: as far as your comment goes about Asterisk not updating the SSRC ID when switching from early media to an answered call: does that adversely affect any known devices? By: David Woolley (davidw) 2012-07-17 05:56:38.540-0500 The only problems we have observered is when there is a discontinuity in the timestamps, but no corresponding change in the SSRC, specifically for an AgentLogin agent during the MoH to beep to through audio transition.  Without an SSRC change, Cisco phones on the far side of CUCM, but with direct media, buzz at the frame rate for some time.  I don't believe excess SSRC changes would cause problems. By: Olle Johansson (oej) 2013-09-05 04:28:12.816-0500 What's the status on this bug report? Does Microsoft has any technichal reason not to accept SSRC changes? Are you using SRTP? By: Torrey Searle (tsearle) 2013-10-31 03:41:02.668-0500 From my personal viewpoint we have had customer complains of one way audio when srcc changes (I don't have the equipment references, seems locking onto an ssrc is a common practice) I have some comments with regards to this patch: 1. this patch adds a config option to disable p2p bridge.. there are already cases already where that would happen e.g. if you need to convert between DTMF INFO and RFC2833  this patch cannot introduce a bug that doesn't already exist 2. RTP frames include timing information in them.  So there should no jump in timestamps between the early bridge and the native bridge afterwards As a more generic solution may I suggest the following: in ast_rtp_read move the SSRC change detection logic to be just before bridge_p2p_rtp_write (instead of just after) modify bridge_p2p_rtp_write to re-write the ssrc and seqno of the rtp struct already has a ssrc defined (timing shouldn't need to be re-written as it was never-rewritten) What do you guys think? By: Olle Johansson (oej) 2013-10-31 03:48:33.402-0500 One problem is that Asterisk quite often send two answers to an SDP offer. One in 183 and another slightly different in the 200 OK - but with the same tags and call-id. If we changed our tag in the 200 ok it would look to the other side as another established dialog, not the same as the early dialog. We need to fix that, but I doubt that unless we also change port the other side will see it as a new RTP stream. We could potentially also continue to use the same SSRC and add the new SSRC from the RTP bridge as an CSRC. I am looking into this now. By: Olle Johansson (oej) 2013-10-31 03:49:30.478-0500 While turning of p2p bridge may be a solution, I don't think it's the solution we should go for. By: Torrey Searle (tsearle) 2013-10-31 04:30:33.306-0500 Olle I think the 183 / 200 OK issue has already been fixed by us in asterisk trunk r400912 (see ASTERISK-21204) From my testing with Dialogic equipment, I find that when the 183 / 200 ok of asterisk match, dialogic will send a continous rtp stream between early and established dialog w/o any ssrc change. By: Olle Johansson (oej) 2013-10-31 04:44:42.072-0500 The problem is that we may want to change codec in the 200 OK since we have a bridge. So we may want to be able to send two answers... Will have to look into what happened with ASTERISK-15001 and ASTERISK-21204. The commits are not in the issue tracker. By: Andre Di Genova (AndrePew) 2014-01-21 22:34:21.489-0600 The changing of SSRCs on bridging also causes problems with Google's implementation of WebRTC. The changing of SSRCs results in loss of audio being sent by Asterisk. Internally I think they use SSRC to keep track of audio streams in libjingle.