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

On Wed, Apr 30, 2014 at 8:46 AM, Emil Ivov <emcho@jitsi.org> wrote:

>
>
> On 30.04.14, 17:22, Peter Thatcher wrote:
>
>>
>>
>>
>> On Tue, Apr 29, 2014 at 10:42 PM, Emil Ivov <emcho@jitsi.org
>> <mailto: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.
>>
>
> Could you please explain why?
>
>
>  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.
>>
>
> Easiest for who? From a web dev's perspective it would probably be much
> more intuitive to say "this sender and receiver belong to the same context"
> than "you need to extract the value of the 'four funky letters' in the
> receiver and set it on the 'four funky letter' in the sender".


​I really don't want to start requiring the JS to correlate RtpSenders and
RtpReceivers into "contexts" just to work around the oddities of RTCP.
 "contexts" are just going to turn into complex rat holes.  For the
normal/simple cases of using the API, I think just not setting it and using
the default (either ssrc=1 or random) will work fine.  It's only in interop
cases that you'll need something more complex, and at the point, you'll
want enough control to just set it.


>
>
>      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.
>>
>
> It's not about the SFU being confused. Some SFUs (because there's more
> than one in the market ;) ) would just forward all RTP and RTCP to everyone
> else so it will be up to the endpoints to distinguish them.

​
I consider that an interop uses case that could set the SSRC how it needs
it.​



>
>
>          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.
>>
>
> Neither do I (and this goes for both RTP and RTCP).
>
>
>  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.
>>
>
> Maybe, although given Chrome's overall fetish with SSRCs and how it
> insists on knowing everything in advance it kind of fits into a pattern.
>
>  By the way, it also special cases SSRC=1, such
>> that it never drops the RTCP when SSRC=1.
>>
>
> Good to know.
>
> Emil
>
>
>>     Cheers,
>>     Emil
>>
>>
>>
>>         -Robin
>>
>>             Peter Thatcher <mailto:pthatcher@google.com
>>             <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
>>
>>
>>
> --
> https://jitsi.org
>