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

On 30.04.14, 17:50, Robin Raymond wrote:
>> 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.

This justifies a need to obtain it. I don't see how it's a reason to set 
it though.

>> ​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".

I disagree. I seriously don't want to care about setting SSRCs as a JS 
developer. Because it is an unusable value, defaulting it to "1" 
requires me to care (and it also requires me to learn RTP).

I don't see what the issue is with defaulting to a valid, random SSRC?

> 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.

Absolutely true but conflicts would need to be handled no matter how we 
assign the SSRC. There would always be a chance that one may happen, 
even when the developer is setting it.

> 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.

A valid SSRC (other than 1) would solve this issue and you would still 
not need it to be settable.

The only reason I see for a settable SSRC is if for some reason you want 
to signal it before you even created your Sender / Receiver object. So, 
I don't really mind to make that possible.

What I do object to is to make setting it mandatory and, again, 
defaulting to "1" and not handling conflicts would have that effect.

Cheers,
Emil

-- 
https://jitsi.org

Received on Wednesday, 30 April 2014 16:00:42 UTC