Project: webrtc Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 21 users
Status: Available
Owner: ----
Cc:
Components:
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 a...@tokbox.com, May 14 2014 Back to list
What steps will reproduce the problem?
1. Open https://apprtc.appspot.com 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. "
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-13

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 braveyao@webrtc.org, May 15 2014
Cc: jiayl@webrtc.org braveyao@webrtc.org
Owner: juberti@webrtc.org
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 juberti@webrtc.org, May 30 2014
Cc: pthatcher@webrtc.org
Labels: Area-PeerConnection Mstone-37
Owner: braveyao@webrtc.org
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 braveyao@webrtc.org, Jun 4 2014
Sure. My chromium updating had some problem. Now it's fixed. Would track into it soon.
Project Member Comment 4 by braveyao@webrtc.org, 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 braveyao@webrtc.org, Jun 6 2014
Cc: wu@webrtc.org perkj@webrtc.org
Owner: juberti@webrtc.org
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 juberti@google.com, 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 juberti@webrtc.org, Jun 7 2014
Owner: braveyao@webrtc.org
Project Member Comment 8 by braveyao@webrtc.org, Jun 9 2014
Cc: juberti@webrtc.org
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.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/media/webrtc/webrtcvideoengine.cc&q=WebRtcVideoMediaChannel::OnPacketReceived&sq=package:chromium&type=cs&l=2766

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.
https://sites.google.com/site/webrtc/reference/webrtc-internals/viertp_rtcp#TOC-Class-ViERTPObserver.

No idea which is more suitable to the current libjingle structure. Please help to evaluate!
Comment 9 by wu@webrtc.org, 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 braveyao@webrtc.org, Jun 13 2014
Cc: -juberti@webrtc.org
Owner: juberti@webrtc.org
Comment 11 by juberti@google.com, Jun 14 2014
Owner: wu@webrtc.org
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.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/statscollector.cc&l=616


Comment 13 by wu@webrtc.org, Jul 25 2014
Labels: -Mstone-37
Owner: juberti@webrtc.org
Status: Untriaged
Assign to Justin for triage.
Project Member Comment 14 by pthatcher@webrtc.org, 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 braveyao@webrtc.org, Oct 17 2014
Cc: guoweis@webrtc.org
+Guowei
Project Member Comment 16 by pthatcher@webrtc.org, Jan 7 2015
Labels: -Mstone-41 Mstone-42
Project Member Comment 17 by pthatcher@webrtc.org, 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 tnakamura@webrtc.org, Jan 29 2016
Status: Fixed
Seems fixed to me in 49.0.2623.23. This was probably addressed a while back, but I don't know exactly when. 
chrome-webrtcinternals-m49.png
200 KB View Download
Comment 19 by phil...@tokbox.com, 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 tnakamura@webrtc.org, Jan 30 2016
Cc: -wu@webrtc.org hta@webrtc.org
Labels: -Mstone-44
hta@ - can you share your thoughts about #19?
Comment 21 by tsa...@testrtc.com, 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 juberti@webrtc.org, Jan 30 2016
Status: Available
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 tnakamura@webrtc.org, Feb 1 2016
Cc: juberti@webrtc.org
Owner: ----
Available == "Triaged, but no owner assigned," so I'm clearing the owner field. Volunteers welcome!
Project Member Comment 24 by hta@webrtc.org, 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 https://bugs.chromium.org/p/webrtc/issues/detail?id=5499#c1 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 wx3...@gmail.com, 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 pthatcher@webrtc.org, Nov 8 2016
Components: -PeerConnection Stats
Labels: -EngTriaged
This is still a problem with new getStats
Sign in to add a comment