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

On Tue, Apr 29, 2014 at 10:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey folks,
>
> I personally don't see the need to set the SSRC (just as there is no need
> to do it for bidirectional RTP) but I do agree there has to be a way to
> obtain it from the API. We actually also need that in the case when we have
> disparate numbers of multiple senders and receivers and it can no longer be
> assymed what SSRC is used where.
>
>
I'm pretty sure we need it at least for the 1.0 shim.  And I'm sure there
are legacy interop scenarios the JS will need to specify the RTCP SSRC, and
letting the browser choose won't be enough.  In particular, I'm thinking of
how it will want to correlate the RTCP SSRC of an RtpReceiver with the RTP
SSRC of an RtpSender.  I think letting the JS specify the RTCP SSRC in the
RtpReceiver is the easiest way.



> more inline:
>
>
> On 30.04.14, 04:23, Robin Raymond wrote:
>
>>
>> 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.
>
>
> Agreed. SSRC=1 will become messy when multiple receivers are sending RTCP
> (e.g. in an SFU conference) so a random generated SSRC would be much better.


​I'm not sure why SSRC=1 would be a problem in an SFU situation.  If
multiple receivers are all sending with SSRC=1, why would the SFU get
confused?  They are all coming in from different connections anyway.


>
>  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.
>>
>
> In the current WebRTC implementation Chrome seems to be ignoring RTCP FIRs
> from SSRCs that it doesn't know. I don't exactly know what the reason is
> (pacing i-frames?) but it is one reason why you'd need it signalled.
>

​Yeah, that's kind of why I asked if we need to signal this at all.  In
principle, I don't see a reason it needs to be.  Put in practice, in Chrome
right now, if you don't signal the SSRC you're going to send RTCP with,
Chrome will drop the RTCP on the receive side (sometimes; it's
complicated).​  But it's possible that wasn't intentional; It may have just
been an oversight.  By the way, it also special cases SSRC=1, such that it
never drops the RTCP when SSRC=1.


>
> Cheers,
> Emil
>
>
>
>> -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.
>>>
>>>
> --
> https://jitsi.org
>