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|
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?
May 30 2014,
Yes, we absolutely should. I don't know why this doesn't work. Brave, can you take a look at this?
Jun 4 2014,
Sure. My chromium updating had some problem. Now it's fixed. Would track into it soon.
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?
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.
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?
Jun 7 2014,
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. 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!
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?
Jun 13 2014,
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?
Jun 16 2014,
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
Jul 25 2014,
Assign to Justin for triage.
Oct 16 2014,
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.
Oct 17 2014,
Jan 7 2015,
Feb 19 2015,
This looks like it's not going to make it in M42. Please update it if I'm wrong.
Jan 29 2016,
Seems fixed to me in 49.0.2623.23. This was probably addressed a while back, but I don't know exactly when.
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.
Jan 30 2016,
hta@ - can you share your thoughts about #19?
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.
Jan 30 2016,
Feb 1 2016,
Available == "Triaged, but no owner assigned," so I'm clearing the owner field. Volunteers welcome!
Feb 3 2016,
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.
Feb 3 2016,
I can provide a concrete case (or two?), but we will need to take it offline to coordinate.
Feb 7 2016,
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:
Mar 18 2016,
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.
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
Nov 8 2016,
Sep 5 2017,
This is still a problem with new getStats
Issue 9016 has been merged into this issue.
#30: is this still an issue in the new stats in canary/stable? issue 9016 suggests some of this might have been fixed
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 https://bugs.chromium.org/p/webrtc/issues/detail?id=8158 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."
Sign in to add a comment