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

[RR] See inline


> Peter Thatcher <mailto:pthatcher@google.com>
> April 30, 2014 at 11:22 AM
>
>
>
> On Tue, Apr 29, 2014 at 10:42 PM, Emil Ivov <emcho@jitsi.org 
> <mailto:emcho@jitsi.org>> wrote:
>
>     Hey folks,
>
>     [...]
>
>
> 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.
[RR] Agreed. It's likely needed for legacy reasons and I can see needing 
to set if if you want to gather stats about "how well did Bob vs Charles 
receive the stream broadcasted by Alice". That would require distinction 
between who is Bob vs Charles by way of a source identifier.
>
>     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.

[RR] If it's settable, I think it's a non issue to default to "1". 
Perhaps it's more ideal since there's a chance a random conflict could 
happen if the browser engine randomly chose an SSRC source ID which 
happen to match some other random sender's SSRC by accident and therefor 
caused a mismatch of who is reporting on what stream. Having said that, 
there are some topologies where JS developers might want to chose a 
value other than "1" and not just for legacy support reasons. For 
example, if Alice were sending out a broadcasted RTP stream via an 
intermedia server box to Bob, Charles and Debbie where the broadcast 
server would forward RRs (Receiver Reports) back to Alice, she would 
receive RRs from each party as seen from the broadcasting server's 
source IP address. So Alice can't tell who sent which RR in that case 
for statistics purposes and it might confuse the engine who is reporting 
which statistic. Bottom line: allowing JS app developer to override the 
default value of "1" sounds like a very reasonable default behaviour for 
most (IMHO), or alternatively having the engine chose a random default 
value if unset is okay too.
>
>
>
>         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.
[RR] Sounds like an implementation issue and rather than problem with 
the idea.
>
>
>     Cheers,
>     Emil
>
>
>         [...]
>