New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 3342 link

Starred by 25 users

Issue metadata

Status: Fixed
Closed: Jun 19
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Missing ssrc_ section in getStats when receiving from client with no a=ssrc lines

Reported by, May 14 2014

Issue description

What steps will reproduce the problem?
1. Open in Chrome
2. Open the same apprtc room in Firefox
3. Go to chrome://webrtc-internals/ in Chrome

What is the expected result?

There would be a "Stats graphs for ssrc_[some number]" section on the page which provides eg. audioOutputLevel, bitsReceivedPerSecond, packetsReceivedPerSecond etc.

What do you see instead?

This section is completely missing from webrtc-internals. These properties are also missing if you call getStats on the PeerConnection in JavaScript. This is the main issue, we would like to use the audioOutputLevel.

What version of the product are you using? On what operating system?

Mac OSX, Chrome Version 34.0.1847.131
Firefox 29.0.1 (also Firefox Nightly 32.0a1 (2014-05-13))

Please provide any additional information below.

Firefox doesn't provide the ssrc attribute in the offer which is probably causing the issue. Apparently this is legitimate and this section is optional:

"Use of the "a=ssrc:" attribute to signal SSRC identifiers in an RTP session is OPTIONAL. "

It seems though that Chrome expects this value to be there when generating the stats.

Chrome to Chrome with ssrc stats.png
201 KB View Download
Chrome to Firefox missing ssrc stats.png
158 KB View Download
Project Member

Comment 1 by, May 15 2014

Yes, FF won't have SSRC in its SDP, so chrome has to generate a default SSRC internally to make the call running.

@justin, is it possible to show the stats of the default SSRC?
Project Member

Comment 2 by, May 30 2014

Labels: Area-PeerConnection Mstone-37
Status: Assigned
Yes, we absolutely should. I don't know why this doesn't work. 

Brave, can you take a look at this?
Project Member

Comment 3 by, Jun 4 2014

Sure. My chromium updating had some problem. Now it's fixed. Would track into it soon.
Project Member

Comment 4 by, Jun 5 2014

Some update:
In chrome <--> FF case, we could collect the stats of incoming streams, but would fail to prepare the report. In StatsCollector::PrepareLocalReport() we couldn't get the track ID by SSRC. It seems like we didn't bind the default SSRC with the incoming track/stream. Would try to check that part tomorrow. 
Does anyone already have any idea?
Project Member

Comment 5 by, Jun 6 2014

Here is  my finding. Please help to correct if I'm wrong or missing anything:

We would generate default stream/track with default label/id, if the incoming SDP has none SSRC lines. But the SSRC number is still lacking here. So we would fail to get the track ID by SSRC.
WebRTC would get the SSRC from the RTP packets and put it in the statistics.

I suppose one solution might be to complement the SSRC info after RTP packets is got. Libjingle could either retrieve it from RTP packet or from WebRTC API.
Any other idea?

@justin, please help to triage.

Comment 6 by, Jun 6 2014

Right, I think we should record the SSRC of the default stream and use that. Brave, can you tell which API call is not working in this case?
Project Member

Comment 7 by, Jun 7 2014

Project Member

Comment 8 by, Jun 9 2014

Libjingle would parse the SSRC from the received packet too to pick the processing channel. If there is no match, then it would forward packets to the default channel. I suppose we could record the SSRC to the default channel here.

Another way is Libjingle could register the RTPObserver callback to ViE/VoE. Then it could receive the IncomingSSRCChanged() callback to be notified the incoming SSRC change and keep it synced between Libjingle and webrtc, no matter whether there is SSRC lines in SDP or not.

No idea which is more suitable to the current libjingle structure. Please help to evaluate!

Comment 9 by, Jun 9 2014

WebRtcVideoMediaChannel::OnPacketReceived seems like a good place to config default channel's ssrc. You also need to do similar thing for audio as well.

Wdyt Justin?
Project Member

Comment 10 by, Jun 13 2014


Comment 11 by, Jun 14 2014

I still don't quite understand the problem. We'll use the default channel for handling the incoming video, and then when we call GetStats, we'll loop over all recv_channels_, which includes the default channel.

As long as GetRemoteSsrc doesn't return 0 (which I don't think it should), the default channel should be included in the stats.

Ronghua, what am I missing here?
I chatted with Brave, the problem is actually the lack of the connection between a remote media track and a stats report.

When remote sdp is applied, we create remote stream and track. The track doesn't have ssrc in the firefox case.

Later when we call GetStats into the WebRtcVideoMediaChannel, we get the stats report identified by SSRCs. However, when we try to link the report with the remote track, we failed. This is because the remote track doesn't know about the ssrc.

Comment 13 by, Jul 25 2014

Labels: -Mstone-37
Status: Untriaged
Assign to Justin for triage.
Project Member

Comment 14 by, Oct 16 2014

Labels: EngTriaged Mstone-41
Guowei, here is another place where you can learn the code here a bit, and in a way that's not risky.  If you need to understand things down at the engine level, you can ask me about it.  
Project Member

Comment 15 by, Oct 17 2014

Project Member

Comment 16 by, Jan 7 2015

Labels: -Mstone-41 Mstone-42
Project Member

Comment 17 by, Feb 19 2015

Labels: -Mstone-42 Mstone-44
This looks like it's not going to make it in M42.  Please update it if I'm wrong.
Project Member

Comment 18 by, Jan 29 2016

Status: Fixed (was: Untriaged)
Seems fixed to me in 49.0.2623.23. This was probably addressed a while back, but I don't know exactly when. 
200 KB View Download

Comment 19 by, Jan 29 2016

@tnakamure: Firefox now sends a a=ssrc line which means this is no longer such an issue. I don't think there was a chrome-side fix for this so it is still an issue for legacy gateways. Maybe hta@ has an opinion on this.
Project Member

Comment 20 by, Jan 30 2016

Labels: -Mstone-44
hta@ - can you share your thoughts about #19?

Comment 21 by, Jan 30 2016

This is still an open issue. While Firefox might be sending an a=ssrc line, we are seeing this issue coming up a lot when running Chrome against SIP PBXs that got SIP over WebSocket support added to them. They don't send that line, so we can't really collect and analyze the data at all.
Project Member

Comment 22 by, Jan 30 2016

Status: Available (was: Fixed)
Summary: Missing ssrc_ section in getStats when receiving from client with no a=ssrc lines (was: Missing ssrc_ section in getStats when receiving from Firefox)
Project Member

Comment 23 by, Feb 1 2016

Owner: ----
Available == "Triaged, but no owner assigned," so I'm clearing the owner field. Volunteers welcome!
Project Member

Comment 24 by, Feb 3 2016

Labels: Spec-W3C
I would like to see a concrete case where it's an issue (including having an owner who can verify the fix if we produce one).

It should be easy to reproduce the issue with SDP mangling, but it seems a shame to do repairs against an unknown target.

Adding Spec-W3C since this affects getStats results.
I can provide a concrete case (or two?), but we will need to take it offline to coordinate.
note: while this works in general, a lot of receive statistics are broken. E.g. in the dump attached to it looks like some stats are for one ssrc, others are for the other. That is largely an issue of proper mapping of Firefox's a=msid: to chrome's a=ssrc:12345 msid:
I could also verify the fix if you produce one. We are running a setup where the webrtc client makes and receives calls through a SIP media gateway (asterisk 13). Asterisk 13 never sends ssrc attributes in its outbound SDPs and consequently our client cannot make full use of the getStats api, which we would like to do to analyze audio quality.  

Comment 28 by, Oct 29 2016

Is there any updated information regarding this issue? It's really problematic to analyze the quality of the mediastream without the _recv-sections of the getStats() ... Our remote UA is a PBX that won't send ssrc attributes in SDP
Project Member

Comment 29 by, Nov 8 2016

Components: -PeerConnection Stats
Labels: -EngTriaged
This is still a problem with new getStats
Project Member

Comment 31 by, Mar 20 2018

 Issue 9016  has been merged into this issue.

Comment 32 by, Mar 20 2018

#30: is this still an issue in the new stats in canary/stable?  issue 9016  suggests some of this might have been fixed
Project Member

Comment 33 by, Mar 20 2018

Adding some keywords so I find this next time I search for it: "Unsignaled SSRCs", "Unsignalled SSRCs"

To answer fippo's question, the new/standards-compliant getStats should return stats for unsignaled streams, though there are still caveats; see

The legacy getStats hasn't been fixed though. Copying description from  issue 9016 :

"You'll find this error message in the log: "The SSRC X is not associated with a receiving track". Basically, the stats collector is using the SSRC to match receive stream stats to tracks, and it does this by looking in the SDP.

The new stats collector doesn't have this problem because it uses "TrackMediaInfoMap", and gets the SSRC from the RtpReceiver (which hops threads and gets it from the media engine). So the problem could be fixed by doing something similar. Or just returning a stats object with a missing track ID, which may be good enough for a lot of people."
Project Member

Comment 34 by, Jun 19

The following revision refers to this bug:

commit a465344e395cddf1ac4c947cf797297979a50090
Author: Taylor Brandstetter <>
Date: Tue Jun 19 17:28:25 2018

Return SSRC stats with the old stats API when SSRCs are unsignaled.

This is the simplest possible fix, returning SSRC stats with a missing
track ID instead of returning no SSRC stats at all.

This means calling GetStats with the track selector argument will still not
work in this case.

Bug:  webrtc:3342 
Change-Id: I6b58fd5ac15b49274d3f1655e78ae36c4575e5fd
Commit-Queue: Taylor Brandstetter <>
Reviewed-by: Henrik Boström <>
Cr-Commit-Position: refs/heads/master@{#23667}

Project Member

Comment 35 by, Jun 19

Labels: M-69
Status: Fixed (was: Available)
The above CL will cause SSRC reports to be generated, just with missing track IDs (which also means the track "selector" argument won't work). Not perfect, but given that the legacy stats implementation is on life support, I think that should be enough to consider this fixed.
We still see this problem with Chrome 69.0.3464.0
works in 69.0.3472.3
Yap. Confirmed this is now fixed on 69.0.3472.3
Project Member

Comment 39 by, Jul 31


Sign in to add a comment