Re: I think we need a way to configure the RTCP SSRC.

You are correct. This is an oversight.

The receiver must emit a "sender SSRC". Typically in a bi-directional 
scenario the client would pick the SSRC of the sending stream to 
indicate receiver reports. But when you have 1-way streams or uncouple 
the sender from the receiver, it's not clear what value should be picked.

My answers would be:
1) If not specified, system can pick one. It can chose an SSRC "source" 
to put into the receiver report from a sender within the same "RTC 
context" if one exists, or just chose a new SSRC at random. Either would 
work satisfactory IMHO.
2) Not that I'm aware. I don't see what the browser engine would do with 
that information. Worse, if the send stream was broadcasted to multiple 
receivers, there would be multiple parties reporting about the same SSRC 
each with having their own source SSRC. Perhaps an app level would want 
to know the stats reported by each receiver source but I don't see the 
value in telling the sender engine what SSRC value(s) to expect from the 
receiver's source in advance.

-Robin

> Peter Thatcher <mailto:pthatcher@google.com>
> April 29, 2014 at 3:20 PM
> One thing that I think we have overlooked is how the JS can configure 
> the SSRC to go in RTCP packets.
>
> For example, if I do this:
>
> var rtpReceiver = new RTCRtpReceiver(...);
> rtpReceiver.receive(...);
>
> At this point, the rtpRecever knows how to receiver RTP.  But to send 
> back RTCP, the RtcpReceiver needs to know which SSRC to send the RTCP 
> with.  In the typical 1:1 WebRTC 1.0, SDP-based scenario, this is done 
> with the SSRC used to send RTP.  In ORTC lingo, that means it assumes 
> the existence of an RtpSender with a configured sendSSRC.  Obviously 
> we can't make this assumption, and it seems to me that RTCP is kind of 
> broken for the one-way-media case.
>
> So what can we do?  One simple solution is to let the JS sepecify the 
> SSRC that the RtpReceiver should use to send RTCP.  That way, 1.0 
> shims can use this to configure RTCP correctly, and pure ORTC clients 
> can make sure that an SSRC is properly configured.
>
>
> So I propose we add this:
>
> dictionary RTCRtpParameters {
>   // all the other stuff (codecs, layers, extensions)
>   unsigned int rtcpSsrc;
> };
>
> When used in RtcpReceiver.receive(), it will control what SSRC to use 
> when sending RTCP.
>
> The questions I have that I'm not quite clear on are:
>
> 1. What should the browser do if it's not set?  Not send RTCP? Just 
> pick an SSRC?   I'm inclined to just say use ssrc=1, but that sounds 
> too easy, so there must be some old RFC that says we're not allowed to 
> do that.
>
> 2. Does this value need to be set in the RtpSender to let it know the 
> SSRC to expect?  In other words, does this value need to be signalled? 
>   I don't see why it really needs to be, but demux is complex, and so 
> there might be some reason it would be needed for demux.
>