Support for un-announced SSRCs
Reported by em...@sip-communicator.org, May 14 2013
What steps will reproduce the problem? Sending multiple SSRCs to Chrome without first announcing them in an SDP Offer or Answer. If this is insufficient, we'll try to come up with a more specific reproduction scenario and possibly a test bed later this week. What is the expected result? According to draft-ietf-mmusic-msid-00, Section 4.1: All incoming SSRCs, on all m-lines that are part of the SDP session, are assumed to belong to independent media streams, each with one track. The identifier of this media stream and of the media stream track is a randomly generated string; the label of this media stream will be set to "Non-WMS stream". What do you see instead? As long as Chrome receives packets from a single SSRC, all works well regardless of whether or not it has been announced. Once Chrome starts receiving packets with a second SSRC it does not create a second media stream as described above and the rendering of the existing stream becomes garbled.
May 14 2013,
Corresponding rtcweb discussion: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07505.html
May 16 2013,
@Justin, please help the arrangement!
May 16 2013,
Because of the many open issues regarding this (e.g. how should RTCP for unknown SSRCs be handled) I don't think we will do anything until the Plan A vs B discussion has been fully resolved.
Dec 5 2013,
Now that the Plan wars are over, would it be possible to fix this? Today, draft-ietf-mmusic-msid-02 Section 4.1 still says: o No msid-semantic:WMS attribute is present. The SDP session is assumed to be a backwards-compatible session. All incoming media, on all m-lines that are part of the SDP session, are assumed to belong to independent media streams, each with one track. The identifier of this media stream and of the media stream track is a randomly generated string; the label of this media stream will be set to "Non-WMS stream". http://tools.ietf.org/html/draft-ietf-mmusic-msid-02#section-4.1
Dec 5 2013,
I'd like to chime in... developing against Emils Videobridge it seemed the current behaviour with unannounced SSRCs (without any a=ssrc line; implementing Plan B ... works like charm) chrome attempts to display all video sources in the same video element which gives very funny effects. I assume required this is for Firefox compability though.
Dec 5 2013,
This was discussed at the Nov 12 W3C meeting, see http://www.w3.org/2013/11/12-webrtc-minutes.html; the conclusion was to stuff the unannounced SSRCs into new MSTracks in a single default MediaStream. But no, this has not yet been implemented; there are several things ahead of it on the priority list.
Dec 16 2014,
Jan 6 2015,
Harald, do you recall what we decided to do about this case in the spec discussions? Is my comment in #6 correct?
Jan 7 2015,
Yes, I believe #6 is correct. Each PeerConnection can have one MediaStream with a randomly generated ID (EKR's comment in the minutes), containing one track per SSRC. Each track will be announced in an addtrack event (once doohickeys are in).
Nov 8 2016,
Dec 14 2016,
Did we fix this? I am seeing the issue again. Two unannounced SSRCs for Video stream, and the second one seems to be discard, but now with a print [13416:0312/141321.029:WARNING:webrtcvideoengine2.cc(527)] Unknown SSRC, but default receive stream already set.
No, it's not fixed; we still only surface a single MediaStreamTrack per m= section for unannounced SSRCs.
Hmm, in that case, shouldn't we erase the existing channel and recreate for the new SSRC?
It appears it does work that way, at least in tip-of-tree: https://cs.chromium.org/chromium/src/third_party/webrtc/media/engine/webrtcvideoengine.cc?q=webrtcvideoengine.cc&dr&l=491
Thank you. Will try with recent pull and update
Sign in to add a comment