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 20 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Support for un-announced SSRCs

Reported by em...@sip-communicator.org, May 14 2013

Issue description

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.

 
Project Member

Comment 2 by braveyao@webrtc.org, May 16 2013

Cc: hta@webrtc.org wu@webrtc.org braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: juberti@webrtc.org
@Justin, please help the arrangement!
Project Member

Comment 3 by juberti@webrtc.org, 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.
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


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.
Project Member

Comment 6 by juberti@webrtc.org, 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.
Project Member

Comment 7 by juberti@webrtc.org, Dec 16 2014

Labels: Area-PeerConnection
Project Member

Comment 8 by juberti@webrtc.org, Jan 6 2015

Cc: -hta@webrtc.org -wu@webrtc.org juberti@webrtc.org
Labels: EngTriaged
Owner: hta@webrtc.org
Status: Available
Harald, do you recall what we decided to do about this case in the spec discussions? Is my comment in #6 correct?

Comment 9 by hta@google.com, 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).
 
Project Member

Comment 10 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 11 by anatolid@webrtc.org, Dec 14 2016

Cc: hta@webrtc.org
Owner: ----
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.


DC_1.5.9.chrome.log
446 KB View Download
Project Member

Comment 13 by deadbeef@chromium.org, Mar 13

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?
Thank you. Will try with recent pull and update

Sign in to add a comment