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

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.