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.
Issue 1772 Support for un-announced SSRCs
Starred by 15 users Reported by em...@sip-communicator.org, May 14 2013 Back to list
Status: Available
Owner: ----
Cc:
Components:
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
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
Cc: hta@webrtc.org
Owner: ----
Sign in to add a comment