You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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].
w3c#59
-Fixes for error handling, as described in Issue 75
w3c#75
- Fixes for miscellaneous NITs, as described in Issue 76
w3c#76
- Enable retrieval of the SSRC to be used by RTCP, as described in Issue 77
w3c#77
- Support for retrieval of audio and video capabilities, as described in Issue 81
w3c#81
- getStats interface updated, as described in Issue 82
w3c#82
- Partially addressed SVC issues described in Issue 83
w3c#83
- Partially addressed statistics update issues described in Issue 85
w3c#85
From: Peter Thatcher
Date: Tue, 29 Apr 2014 12:20:46 -0700
To: "[email protected]" [email protected]
URL: http://lists.w3.org/Archives/Public/public-ortc/2014Apr/0140.html
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:
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.
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.
The text was updated successfully, but these errors were encountered: