Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuring the RTCP SSRC #77

aboba opened this issue May 2, 2014 · 1 comment

Configuring the RTCP SSRC #77

aboba opened this issue May 2, 2014 · 1 comment


Copy link

aboba commented May 2, 2014

From: Peter Thatcher
Date: Tue, 29 Apr 2014 12:20:46 -0700
To: ""

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(...);

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.
Copy link
Contributor Author

aboba commented May 7, 2014

How about this?

dictionary RTCRtpParameters {
DOMString? receiverId = "";
sequence codecs;
sequence headerExtensions;
sequence encodings;
unsigned int rtcpSsrc = null;

rtcpSsrc of type unsigned int, defaulting to null

The SSRC used by RTCP (e.g. in Receiver Reports), null if unset. If null, the SSRC is chosen by the browser. Note that the browser may change the SSRC in event of a collision, as described in [RFC3550].

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue May 14, 2014

-Fixes for error handling, as described in Issue 75

- Fixes for miscellaneous NITs, as described in Issue 76

- Enable retrieval of the SSRC to be used by RTCP, as described in Issue 77

- Support for retrieval of audio and video capabilities, as described in Issue 81

- getStats interface updated, as described in Issue 82

- Partially addressed SVC issues described in Issue 83

- Partially addressed statistics update issues described in Issue 85
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants